unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 8951@debbugs.gnu.org
Subject: bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names
Date: Mon, 4 Jul 2011 14:08:19 -0700	[thread overview]
Message-ID: <375C29E7AB4048148D18B461FC1E02F1@us.oracle.com> (raw)
In-Reply-To: <jwvbox94wxv.fsf-monnier+emacs@gnu.org>

> > 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	other threads:[~2011-07-04 21:08 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-27 19:13 bug#44909: Hyperlinks gone for first story of two-storied *Help* buffers 積丹尼 Dan Jacobson
2020-11-28  7:39 ` Eli Zaretskii
2020-11-28  7:56   ` Stefan Kangas
2011-06-28 16:38     ` bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names Drew Adams
2011-07-04 20:28       ` Stefan Monnier
2011-07-04 21:08         ` Drew Adams [this message]
2011-07-06 18:49           ` Stefan Monnier
2011-07-06 19:55             ` Drew Adams
2011-07-08 19:07               ` Stefan Monnier
2011-07-08 19:20                 ` Drew Adams
2019-06-27 16:35                   ` Lars Ingebrigtsen
2021-10-23  0:46         ` Stefan Kangas
2021-10-24 13:36           ` Lars Ingebrigtsen
2021-10-24 13:54             ` Stefan Kangas
2021-10-24 14:15               ` Lars Ingebrigtsen
2021-10-24 14:56                 ` Stefan Kangas
2021-10-24 21:07           ` bug#8951: [External] : " Drew Adams
2021-10-24 21:37             ` Stefan Kangas
2021-10-24 22:05               ` Drew Adams
2021-10-24 22:24                 ` Stefan Kangas
2021-10-24 22:47                   ` Drew Adams
2021-10-24 23:15                     ` Stefan Kangas
2021-10-25  1:32                       ` Drew Adams
2021-10-25  2:37                         ` Stefan Kangas
2020-11-28 20:45       ` bug#8951: bug#44909: Hyperlinks gone for first story of two-storied *Help* buffers 積丹尼 Dan Jacobson
2020-11-29 10:25     ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=375C29E7AB4048148D18B461FC1E02F1@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=8951@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).