Re: rethinking @def*

[Gavin Smith]

On Wed, Aug 10, 2022 at 05:11:44PM +0200, Patrice Dumas wrote:
> On Wed, Aug 10, 2022 at 03:24:12PM +0100, Gavin Smith wrote:
> > On Wed, Aug 10, 2022 at 10:37:41AM +0200, Patrice Dumas wrote:
> > > 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.
> > 
> > I think it makes sense for @code (and @t) at least, to force an upright
> 
> For @code, ok, but for @t, I disagree.  @t is just a font change
> command, it should not force anything.  If @t is always upright, also,
> then it is impossible to have a slanted typewriter formatting.  It could
> be left undefined and format specific, but forcing @t to be always
> upright (in @def arguments) seems wrong to me.

I don't feel strongly about whether @t should force upright font.  I'm
happy if it is just @code.  I will take the @t out if you haven't already.

I had thought that @code could be forced to be upright on
a slanted @def line, at least.  Whether it should be upright everywhere
else doesn't really matter; we could go with what is the easiest to
implement.  It's probably safest just to keep it to the @def line.