Re: rethinking @def*

[Patrice Dumas]

On Tue, Aug 16, 2022 at 12:01:17PM +0100, Gavin Smith wrote:
> On Tue, Aug 16, 2022 at 11:46:07AM +0200, Patrice Dumas wrote:
> > 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.

In addition (but maybe you need to review the node...) I added an
explicit recommendation of using @r{@t{..}} in 'Marking Definition
Arguments'.

> > 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.

Probably with a focus on TeX and Info, and not HTML.

> @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?

This is what I addedas recommendation, though...  But I also recommended
to use macros such that the absurdity is somewhat hidden...

-- 
Pat