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

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

Re: not good proposal: "C-z <letter>" reserved for users


From: Joost Kremers
Subject: Re: not good proposal: "C-z <letter>" reserved for users
Date: Thu, 11 Feb 2021 09:30:16 +0100
User-agent: mu4e 1.5.8; emacs 27.1.90

On Thu, Feb 11 2021, Robert Thorpe wrote:
> Here are my opinions on these things.
>
> * Moratorium on New Emacs Keybindings.
>
> At present there's lot of work going on outside of core Emacs.  I think
> it makes sense for core Emacs not to use too many keybindings.  I can
> see the sense the argument Drew Adams makes.

Since it's really easy in Emacs to (re)bind keys, I don't really see this as
much of a problem. (Mind you, I'm firmly of the conviction that external
packages should *not* create any global bindings.)

> If a *general* moratorium isn't possible, then how about a more specific
> one?  How about applying it only to certain keymaps or prefix keys.

Which would be equivalent to reserving more keys for users to bind, right?

> * A Prefix-Key for Global Third-Party Packages.
>
> I think this is a good idea too.  

I've explained elsewhere[1] why I think this is not a good idea. Basically, I
don't see a problem here that couldn't be solved much more easily by updating
the keybinding conventions to say that external packages should not create any
global bindings by default.

Reserving keys for external packages means that Emacs needs some way to deal
with conflicting external key bindings, which will inevitably arise. (My own
packages don't create any global bindings, but I'd be very tempted to add them
if this becomes official policy, because it will be what users will come to
expect, and I suspect I won't be the only 3rd-party package maintainer that
feels that way.)

So you'd have to come up with a new function that creates global key bindings,
but checks first to make sure the keys are still free (which, BTW, means the
order in which packages are loaded becomes relevant) and pop up a warning asking
the user what to do if they're not. This choice then has to be saved somewhere,
presumably in `custom-set-variables`.

You'd probably also need to add a customisation option to completely disable
creating 3rd-party global bindings to keep grumpy old (and maybe not so old) men
and women like me happy. Or, to put that in a more positive way: I prefer to
keep my global key bindings in my init file together with the code that loads
the relevant package and not have to consider whether a 3rd-party package messes
with my key bindings somewhere.

Anyway, I feel that you'd end up with a system that is more complex than
necessary for the problem it tries to solve, which isn't that big to begin with
(IMHO, of course).

> There is another issue....  I'm not sure that third-party packages will
> use the feature.  I'm also on the Reddit Emacs group.  Several of the
> people there use and develop third-party packages.  It seems to me that
> they often do that because they don't want to contribute to core.  Some
> don't like the core Emacs development team and don't  agree with their
> direction for Emacs.  So, would they use such a prefix key if it were
> offered?  Perhaps not.

Since it would not only a concession to the Emacs development team but also a
courtesy to one's users, I suspect many package developers will cooperate. Some
won't, of course, but that will always be the case, no matter what solution is
adopted.

Joost



Footnotes:
[1]  https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg00365.html

-- 
Joost Kremers
Life has its moments



reply via email to

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