emacs-devel
[Top][All Lists]
Advanced

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

Re: Experimentally unbind M-o on the trunk


From: Eli Zaretskii
Subject: Re: Experimentally unbind M-o on the trunk
Date: Wed, 10 Feb 2021 19:29:09 +0200

> Date: Wed, 10 Feb 2021 16:56:44 +0000
> Cc: "Alfred M. Szmidt" <ams@gnu.org>, gregory@heytings.org, larsi@gnus.org,
>   bugs@gnu.support, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > This question also goes to everyone else in this long dispute who
> > wants their precious key bindings preserved: why is such a long
> > discussion needed when it is so easy to restore, in your init file, a
> > binding you want preserved?
> 
> Because we care about other people, in particular newbies.

I doubt it.  Because the keybindings which are being discussed as
candidates for usurpation are those most newbies don't know about and
many never will.

> The bindings people are suggesting suppressing are all basic editing
> commands.

I'd say that's the exaggeration of the year.  (Although the year has
just started, so who knows what better exaggerations are yet in our
stars?)

> Another reason is that if somebody rebinds a much used basic command back
> to its traditional key sequence, that blocks out all the potentially
> useful commands which other people now feel free to bind to that key
> sequence.

No new bindings were suggested, mind you.  So I don't understand what
are those potentially useful commands you are already lamenting.
Should we perhaps wait at least until we hear what they are?

> I also don't see that the case has been made for freeing up vast numbers
> of key bindings for external packages.  If I've understood correctly,
> these key sequences are wanted for things like
> `switch-on-foo-minor-mode', where the reserved minor mode bindings are
> not yet available.

No, that's not the issue.  The main issue is the case of packages like
Magit which'd like to be able to bind keys without conflicting with
the core.



reply via email to

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