[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8951: [External] : Re: bug#8951: 24.0.50; [PATCH] enhancement reques
From: |
Drew Adams |
Subject: |
bug#8951: [External] : Re: bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names |
Date: |
Sun, 24 Oct 2021 21:07:53 +0000 |
> >> 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.
- bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names, Stefan Kangas, 2021/10/22
- bug#8951: [External] : Re: bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names,
Drew Adams <=
- bug#8951: [External] : Re: bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names, Stefan Kangas, 2021/10/24
- bug#8951: [External] : Re: bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names, Drew Adams, 2021/10/24
- bug#8951: [External] : Re: bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names, Stefan Kangas, 2021/10/24
- bug#8951: [External] : Re: bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names, Drew Adams, 2021/10/24
- bug#8951: [External] : Re: bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names, Stefan Kangas, 2021/10/24
- bug#8951: [External] : Re: bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names, Drew Adams, 2021/10/24
- bug#8951: [External] : Re: bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names, Stefan Kangas, 2021/10/24