[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rethinking @def*
From: |
Patrice Dumas |
Subject: |
Re: rethinking @def* |
Date: |
Wed, 10 Aug 2022 22:04:23 +0200 |
On Wed, Aug 10, 2022 at 05:07:50PM +0100, Gavin Smith wrote:
> > 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.
>
> I'd hoped we could consider more about where @var should be in
> a variable width font. I'm still tempted to make it unconditionally
> slanted roman everywhere (in LaTeX output, not HTML output).
That would be ok to me. This is already like that for @cite, and it
somehow makes sense to me to consider that the formatting of @var should
be invariant everywhere, given what it represents. It could be slanted
typewriter or slanted roman, but everywhere the same seems the best to
me.
There should be a possibility to do slanted typewriter explicitely on
@def* lines, but it could be with @r{@t{@slanted{...}}}.
> Since @var on a def line is a more important use case than @code, if
> we didn't special case @var then it wouldn't be worth special casing
> @code there either. Then we could avoid layering hacks upon hacks. I
> suspect it would be cumbersome to make the interaction with embrac
> 100% correct.
It would need a bit more code, definitely doable, better if not needed.
> 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.
--
Pat
- Re: rethinking @def*, (continued)
- Re: rethinking @def*, Patrice Dumas, 2022/08/09
- Re: rethinking @def*, Gavin Smith, 2022/08/09
- Re: rethinking @def*, Patrice Dumas, 2022/08/10
- Re: rethinking @def*, Gavin Smith, 2022/08/10
- Re: rethinking @def*, Patrice Dumas, 2022/08/10
- Re: rethinking @def*, Gavin Smith, 2022/08/10
- Re: rethinking @def*, Gavin Smith, 2022/08/10
- Re: rethinking @def*, Patrice Dumas, 2022/08/10
- Re: rethinking @def*, Gavin Smith, 2022/08/10
- Re: rethinking @def*, Gavin Smith, 2022/08/10
- Re: rethinking @def*,
Patrice Dumas <=
- Re: rethinking @def*, Gavin Smith, 2022/08/14
- Re: rethinking @def*, Patrice Dumas, 2022/08/16
- Re: rethinking @def*, Gavin Smith, 2022/08/16
- Re: rethinking @def*, Patrice Dumas, 2022/08/16
- Re: rethinking @def*, Gavin Smith, 2022/08/17
- Re: rethinking @def*, Patrice Dumas, 2022/08/17
- Re: rethinking @def*, Gavin Smith, 2022/08/17
- Re: rethinking @def*, Patrice Dumas, 2022/08/10
- Re: rethinking @def*, Gavin Smith, 2022/08/10
- Re: rethinking @def*, Patrice Dumas, 2022/08/11