emacs-devel
[Top][All Lists]
Advanced

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

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


From: Dmitry Gutov
Subject: Re: discoverability, better defaults and which-key in Emacs
Date: Thu, 8 Feb 2024 15:36:43 +0200
User-agent: Mozilla Thunderbird

On 08/02/2024 15:02, Eli Zaretskii wrote:
Date: Thu, 8 Feb 2024 14:18:34 +0200
Cc: justin@burkett.cc, philipk@posteo.net, luangruo@yahoo.com,
  jb@jeremybryant.net, emacs-devel@gnu.org
From: Dmitry Gutov <dmitry@gutov.dev>

On 08/02/2024 08:59, Eli Zaretskii wrote:
But
I added F1 to that text, which should help if someone did change
help-char.

Whether help-char is changed, or 'C-h' is rebound anyway, can all be
detected at runtime. <f1> can also have a different binding in the
current prefix map--then the new message would be doubly incorrect.

How frequently do people rebind F1?  IME, never.

Sure, likewise with C-h. That's why the original patch was probably okay as-is.

But I don't object to adding runtime detection of the help keys.

Good.

I'd rather we picked one (preferably correct) suggestion and printed that.

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

For context: I customize echo-keystrokes to a very low value and
currently see this help message quite often.

If the message annoys you, you can disable it.

Sure - this is not a deal-breaker. But the more features I disable the less problems I could find while dogfooding. Until now I've been running with it, and it seemed unobtrusive enough.

Runtime detection might even make it occasionally helpful in odd contexts where something shadows the binding.



reply via email to

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