bug#8951: [External] : Re: bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names

[Drew Adams <drew.adams@oracle.com>]

> > Instead of making the choice of whether to fontify/link
> > key descriptions (1) depend only on a user option
> > (dynamically scoped variable) and (2) hard-coupling it
> > to use of the result in a *Help* buffer, I argued for
> > (1) adding an optional arg to `substitute-command-keys'
> > (to make the choice),
> 
> I don't see the use-case.  I know of no places where the added linking
> is not desirable, if the user has already said that she wants it in the
> help buffer.

I'm suggesting it's not only a question of the help buffer,
and not only a question of a user option.  It's about code
that can optionally fontify/link key descriptions.  That
code can be used for *Help*, but it can be used elsewhere
as well.

`substitute-command-keys' is a general function; it's not
used only for *Help* output.  Why not give it an optional
arg to do this font/linkifying?

> > and (2) separating creation of the resulting fontified/
> > linkified key description from its use in *Help* output.
> 
> I agree with this, but as we have discussed elsewhere this goes further
> and deeper than this option.  It would amount to a major rethinking or
> rewrite of help.el itself.  I hope that we will do that, eventually.

I don't know what you mean there, or what other discussion
you're referring to.  See above; the two are related.

`substitute-command-keys' is such a function: it takes a
string and returns a string.  Give it an optional arg to
have the returned string have the properties needed.

This is what the code I use does.  See the patch at the
outset of this bug thread.  (Of course, as discussed in
this thread it will also be good to move everything to
Lisp.  But the separation I'm talking about is not
dependent on our having done that.)