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

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

> >> What is the feature?  Let users click a key description (i.e., a
> >> key name, such as `C-f') in a buffer such as *Help* to see the
> >> associated help.  This applies to key descriptions derived from
> >> \[...] doc patterns (only).
> 
> The attached patch adds a new option `help-mode--add-function-link'
> that when non-nil makes `substitute-command-keys' add a link to the
> `describe-function' for the bound command when inserting keys.
> 
> I have reconsidered my previously held opinion that this should be off
> by default.  From using this patch, I have come to the conclusion that
> this position is wrong, as this is in fact highly useful in places such
> as `M-x ibuffer RET C-h m' and on many other help screen besides.  The
> only adverse effect of enabling it, furthermore, is that you might have
> to hit TAB a couple of times more on some help screens.  So I think
> having it on by default is very much a good thing.

Glad you decided this is worthwhile, after all.

You seem to have ignored this, from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8951#17:

 I gave this reason to make it optional:

 \\[], \\<>, \\{} are about mapping command names to
 corresponding key descriptions - nothing more.  That
 in itself does not say anything about help buffers
 and interactivity (clicking, RET).  The function is
 just a string transducer.

 The common use case for that is of course doc.  And
 the common use case for the doc use case is a help buffer.

 But a string of doc is more general than a help buffer,
 both in terms of string vs buffer and in terms of the
 need for button text properties (interactivity).  There
 could be applications of this function to produce a
 readable string that do not involve a button-clicking
 interactive context.

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), and (2) separating creation of the
resulting fontified/ linkified key description from its
use in *Help* output.

I think my approach is preferable.  I suggest it still.