Re: wrong font shape for `@var` in `@example`

[Gavin Smith]

On Sun, Aug 21, 2022 at 11:24:56AM +0000, Werner LEMBERG wrote:
> 
> [CCing `bug-texinfo` – this was lost by accident, right?]

Yes.

> Two meta-ness levels meet in things like
> 
> ```
> Add command line option @code{--jobs @var{n}}, where @var{n} ...
> ```

Here @var{n} outputs in two different font styles.

> * Input to be entered by the user is usually shown with a typewriter
>   font – and IMHO, *everything* a user should type has to be shown in
>   typewriter.

But they aren't typing the letter "n".

I can see that the typewriter style here groups the --jobs n text
together.  Another way would be to use quotes, like

  Add command line option @samp{--jobs @var{n}}, where @var{n} ...

where @samp would produce single quotes around the option.

> In a similar vein, stuff within an `@example` environment *must* be
> completely typeset in typewriter; the normal use case is to show
> terminal output, or the contents of a configuration file, which is by
> default identified with a fixed-width font.  If, for whatever reasons,
> some variables are shown, they must, again, be typeset in typewriter.

Yes, you've made your opinion clear on this.

> > Specifically, I felt that matching the font style between typewriter
> > and non-typewriter environments was important, so that when
> > documents referred to @var{flubb} in a paragraph it would look the
> > same as @var{flubb} in the code, so that readers could easily look
> > back and forth between the two.
> 
> This might be so if everywhere people would use `@samp` instead of
> `@code`.  However, this is not the reality.

I don't see why @samp makes a difference here.

> I suggest a global customization variable `@varinputstyle` that
> selects the font style if used within `@code`, `@example`, and friends
> (with the default set to the old behaviour for backward compatibility,
> at least for the next version).  Alternatively, leave the behaviour of
> `@var` as is and add a new command that has the new metaness
> properties.

Maybe.