Re: discoverability, better defaults and which-key in Emacs

[Dmitry Gutov <dmitry@gutov.dev>]

On 08/02/2024 15:52, Eli Zaretskii wrote:
>> Date: Thu, 8 Feb 2024 15:36:43 +0200
>> Cc:visuweshm@gmail.com,justin@burkett.cc,philipk@posteo.net,
>>   luangruo@yahoo.com,jb@jeremybryant.net,emacs-devel@gnu.org
>> From: Dmitry Gutov<dmitry@gutov.dev>
>>
>>> How frequently do people rebind F1?  IME, never.
>> Sure, likewise with C-h.
> No, C-h is different.  At least in the past some people wanted it to
> do the same as Backspace (we even have a special mode for that
> contingency).  But F1 was a relatively late addition to Emacs, from
> when people were accustomed to have it invoke some help function, and
> no application I'm aware of has it bound to something else, unlike
> some other Fn keys.  So I'm quite surprised to hear your "sure" above.
> Did you actually see that in the wild?

I have seen neither exactly, but as a data point I can say that sometime 
until 2014 company-mode used <f1> as a binding in company-active-map.

Not in a prefix map (so this is not an exact match), but still in a way 
that prevents help commands such as '<f1> v' from working. Later we 
added 'C-h' for the same binding (because "<f1> is extremely 
touch-typing unfriendly"), but as I'm looking at it now, the <f1> 
binding is still there.

>>> Most people will never rebind C-h.  Those who do could rebind it to a
>>> character that cannot be used in this situation because it is already
>>> bound in various prefix maps.  Having two alternatives there increases
>>> the probability that one of them will work.
>> If we consider the situations where C-h or f1 is rebound, having
>> misleading text in the message (with bindings that don't work) should
>> concern us as well. Even if one of the suggestions is likely to work
>> anyway (while the other doesn't).
> If you can come up with a code that detects at run time that help-key
> and/or F1 was rebound to a key that will not invoke
> describe-prefix-bindings, such a key should indeed better be removed
> from the message.  But can we reliably do that?  If we cannot, having
> two keys there instead of one is better.

I think we should be able to, but since help-key doesn't call any 
command directly through a map or fallback binding of some sort (instead 
it's dispatched ad-hoc), the solution I have tried so far (also using 
substitute-command-keys) did not help.