bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names
Date: Mon, 4 Jul 2011 14:08:19 -0700

> > 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).
> 
> That looks like a good idea.  Have you tried to plug it directly into
> substitute-command-keys instead?  Are there places where such buttons
> become annoying?
> 
> Basically, the thing I don't like about your patch is the resulting
> redundancy between help-substitute-command-keys and
> substitute-command-keys, which could be removed by 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 wrote Lisp, but if someone wants to instead patch the C code for
`substitute-command-keys' then go for it.

The Lisp version I wrote still invokes the original C code for the \\{...} case.
I did not try to rewrite that in Lisp.

IMO, the best solution would be to:

1. Keep the Lisp code I wrote (or similar), renaming it to
`substitute-command-keys'.

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).

Alternatively, you can write #2 in Lisp, if you like.


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.

`substitute-command-keys' produces a string from a string - typically doc.  But
the use of the output string need not be for a *Help* buffer (or similar context
where buttons are appropriate).  There is no reason to always buttonize these
parts of the output string.  Making buttonizing optional provides flexibility,
at no cost.  Nothing would be gained by making it mandatory.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]