Re: rethinking @def*

[Gavin Smith]

On Wed, Aug 10, 2022 at 10:37:41AM +0200, Patrice Dumas wrote:
> On Tue, Aug 09, 2022 at 11:24:44PM +0100, Gavin Smith wrote:
> > On Wed, Aug 10, 2022 at 12:03:17AM +0200, Patrice Dumas wrote:
> > > Hello,
> > > 
> > > With the changes to TeX output, assuming it is more or less final, I
> > > checked the differences between LaTeX and TeX, the differences are
> > > mainly attributable to the combinations or not of fonts (combination in
> > > LaTeX, not in TeX).  In many cases, we do not really care, we simply
> > > need to document that @r{@___{}} should be used.
> > > 
> > > There are two cases that are of interest, though, as they are likely to
> > > be important in practice:
> > > 
> > > @var in @deftype* is slanted typewriter in LaTeX but slanted roman in
> > > TeX.
> > > 
> > > @code (and @t) in @defn* is slanted typewriter in LaTeX but upright 
> > > typewriter
> > > in TeX.
> > > 
> > > What you we do for those two cases?  Try to change one or the other
> > > formatting?  Document that the formatting can be different?
> > 
> > I think it would make sense to change LaTeX output to be like TeX output
> > for these two points.  We could change @var from \textsl{...} to something
> > like \textrm{\textsl{...}} or {\sl ...}.
> 
> Using \textrm doesn't work for code in @defn*, it does not make the font
> upright, I guess, only roman.  The solution that matches better with TeX
> is to use \textnormal{\textsl{...}} for @var + remove the code style to
> get ligatures back, and \textnormal{\texttt{...}} for @code to remove
> combination of fonts for those commands (or some similar constructs).  

I'd like to do this, but just on the @def line, nowhere else.

> Should be do that, which means never have combinations?  If we do that
> for those commands, it would be logical to do it for other specific
> indicatric @-commands, such as @option, @file, @env...?  Combinations
> would only be possible within those commands, and for font commands such
> as @slanted and similar.  That means that something like @var{@code{}}
> or @code{@var{}} will always only apply the internal @-command
> formatting.

This shouldn't be an issue as these other @-commands will not occur
on definition lines very much.