Re: rethinking @def*

[Gavin Smith]

On Tue, Aug 16, 2022 at 11:46:07AM +0200, Patrice Dumas wrote:
> On Sun, Aug 14, 2022 at 09:17:39PM +0100, Gavin Smith wrote:
> > On Wed, Aug 10, 2022 at 10:04:23PM +0200, Patrice Dumas wrote:
> > > > If people wanted upright @code on a slanted @def line then there would
> > > > be other ways to achive this, like doing @r{@code{...}}, or using
> > > > @deftype without a type.
> > > 
> > > I agree, in general this should not be needed for the reasons you
> > > said.  I will give another one, in general it is not a good idea to use
> > > @code to mark anything on a @def* line, as it adds quotes in Info which
> > > will be confusing for many programming languages.  That being said, the
> > > replacement would be @r{@t{...}} which is also a nesting of commands.
> > 
> > We should make @code and maybe @t upright everywhere so it can be
> > used with @defun and other commands.  This is used in the groff
> > manual occasionally, in the arguments.  Here is an example:
> > 
> > @DefreqList {bp, [@Var{page}]}
> > @DefreqItem {bp, @t{+}@Var{page}}
> > @DefreqItem {bp, @t{-}@Var{page}}
> > 
> > which expands after macros to something like
> > 
> > @deffn Request @t{.bp} [@r{@slanted{page}}]
> > @deffnx Request @t{.bp} @t{+}@r{@slanted{page}}
> > @deffnx Request @t{.bp} @t{-}@r{@slanted{page}}
> > 
> > It's the @t{+} and @t{-} which represent literal text in the
> > arguments.
> > 
> > While in theory @deftypefn could now be used instead for this,
> > it would be less disruptive to allow @deffn to be used.
> > 
> > I presume @t was used here to stop quotes appearing in Info.
> > It would seem the simplest solution would be to force uprightness
> > for both @code and @t.
> 
> I am still not convinced for @t.  The current output in HTML is
> combined slanted and typewriter.  I doubt this is on purpose,

Good point.  The output is already inconsistent here.

As far as I can tell, it's a very minor issue as such constructs do
not occur very often in manuals.

I'd rather not introduce an additional difference between @t and
@code here, so if we weren't going to make a change for @t I'd
rather not make a change for @code either.

> but I also doubt that it would be problematic for the groff team
> to change to the groff manual such that @r{@t{+}} is used instead,
> maybe with a macro similar with @Var, if they really want upright
> typewritter everywhere instead of an ambiguous output.  The fact that
> @Var is @r{@slanted{}} actually shows that they are at least to some
> extent aware of the problem of using @slanted{} only with combining
> fonts.

I expect it was trial and error for various output formats and inputs.

@r{@t{...}} could easily be seen to be an absurd construction by
a user who didn't have exactly the right conception of what the @r
command was for, exactly.  @r is for switching to regular, roman type
inside a code environment, and then we are immediately switching back
to a typewriter font with @t?