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

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

> >> getting rid of the C version and only using the new Elisp version.
> > See the emacs-devel thread, where I addressed both of these things.
> > http://lists.gnu.org/archive/html/emacs-devel/2011-06/msg01081.html
> 
> I don't think that quite addresses it.  But, I guess it does 
> indirectly: you apparently haven't found problematic cases
> that require distinguishing help-substitute-command-keys from
> substitute-command-keys.  Instead you just personally prefer 
> to keep the option whether to buttonize or not.

Yes, I suggested that `substitute-command-keys' itself be modified to accept the
optional argument.  I did not try to replace `substitute-command-keys' directly
with a version that has the optional arg to buttonize, because (a) I didn't want
to hack the C code and (b) I didn't want to bother writing the \\{...} code in
Lisp.

> > I wrote Lisp, but if someone wants to instead patch the C code for
> > `substitute-command-keys' then go for it.
> 
> No, I'm not interested in making this C code more complicated.  I want
> to go the other way around.

Glad to hear that.  That's my preference too.

> > The Lisp version I wrote still invokes the original C code for the
> > \\{...} case.  I did not try to rewrite that in Lisp.
> 
> I see.  It should be pretty easy to do, easy exporting the needed
> underlying C function to Elisp, or rewriting it in Elisp (there's no
> good reason to have describe-buffer-bindings written in C, really).

Please, go for it.  I agree.

> > 1. Keep the Lisp code I wrote (or similar), renaming it to
> > `substitute-command-keys'.
> 
> Sounds good.
> 
> > 2. Simplify the original C code to handle just the \\{...} case,
> > rename that function, and use it in #1 to handle the \\{...} parts
> > (just as now, but under its new, {}-specific name).
> 
> Sounds good.
> 
> > Alternatively, you can write #2 in Lisp, if you like.
> 
> Sounds good as well.
> 
> > Wrt your question of whether "there are places where such buttons
> > become annoying": I would say that it does not matter whether there
> > are currently any such places.  There is no reason not to treat the
> > buttonizing as optional.
> 
> Of course there's the reason that providing a choice is never free, so
> we should only provide the choice if there's a good reason for it.

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.

"providing a choice is never free" -

What's the cost?  And what's the cost of always doing the extra lifting of
creating buttons?

Code maintenance will be at least as easy if it is optional, possibly easier
since the additional buttonizing part is well separated.  And not creating
buttons (properties) saves a little time and memory (but that's probably not
very significant).

No, I don't feel strongly about making buttonizing optional.  But I don't see
why you wouldn't do that.