Re: When should we put @key inside @kbd?

[Gavin Smith]

On Sat, Jan 01, 2022 at 03:13:15PM -0700, Karl Berry wrote:
>     I found an inconsistency in the HTML output in the output for @key,
>     depending on whether it was in @kbd or not. It would be slanted only
>     if inside @kbd. 
> 
> Certainly that was an intentional feature, not a random "inconsistency".
> 
> Maybe @key should use the same font as @kbd, rather than always the
> upright font, which seems to be what you've implemented now?
> 
> This relates to @kbdinputstyle. rms instigated that "different font"
> (slanted for typewriter) for @kbd, back in 1997.  See ChangeLog.46 and
> texinfo.texi for that. The stuff about @key should be in the ChangeLogs too.

I'm not surprised the issue goes back a long way.  As far as @kbdinputstyle
is discussed in the manual it doesn't say exactly what the effect on @key
is, only for @kbd.

There seemed to be a general feeling in the 2018 discussion I linked
to that consistently unslanted fonts are good for @key.

I imagine the effect of @kbdinputstyle would continue for the rest of
the contents of a @kbd command, but not have the effect on @key commands
which were inside.

I found this old ChangeLog entry:

Sun Jan 28 21:14:46 1996  Richard Stallman  <rms@mole.gnu.ai.mit.edu>

        * texinfo.tex (\key, \kbdfoo): Use \ttsl unconditionally.
        (\setkeyfont): Definition deleted.

but since then @key has stopped being unconditionally slanted (I didn't
find out when this was).

> 
> If/Since you are going to undo all that, fine by me, but I suggest
> 1) to be sure and update the manual with whatever users are supposed to
> do to get , and
> 2) it would seem strange to me for HTML and PDF/DVI output to behave
> differently, which is what you seem to have implemented. Or maybe not,
> I can't really tell.

I hadn't checked the PDF/DVI output, but doing so, I see the output had
been consistent with what was being done in HTML.  I propose that this is
also changed for PDF/DVI output to unslant @key inside @kbd.