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: Dmitry Gutov
Subject: Re: not good proposal: "C-z <letter>" reserved for users
Date: Mon, 15 Feb 2021 20:28:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 15.02.2021 06:49, Robert Thorpe wrote:
Dmitry Gutov <dgutov@yandex.ru> writes:

On 13.02.2021 09:37, Robert Thorpe wrote:
Dmitry Gutov <dgutov@yandex.ru> writes:

...
Yes.  But I don't think that solves the problems that Gregory Heyting
and Drew Adams are talking about.

Firstly, it can't do anything about changes in keybindings in future
Emacs versions.  Drew tells us that Emacs has recently mapped "C-x x",
"C-x p" and "C-x /".  I'm using Emacs 27.1, so all of those must have
been mapped for Emacs 28 (or perhaps the version after that).

Is that a problem? When such package finds out about a change like this,
they can change the default binding, or they might keep it as it was.

I disagree.  You're asking the authors of third-party packages to
constantly respond to the capricious behaviour of the maintainers.  I
think they're likely to take their efforts elsewhere if that continues.

Third-party developers are used to change, and the direction of emacs-devel is more often thought of as too reactionary or glacial, rather than capricious.

What did create some outcry is how the maintainer made the change without contacting, or really considering, the #1 popular third-party package which has been making use of this binding for years.

I think Third party package authors should not have to do that.  The
maintainers of Emacs should provide a way to deal with the situation.

Wearing my third-party author hat, I can say it's often nice to be able to use/recommend a short key sequence to the users, even if that might lead to some conflicts down the line. Which doesn't happen for years anyway.

After all, the changes like the ones you have mentioned are additive,
both the project keymap and the later addition of buffer-related
commands on 'C-x x'. They haven't been there before, and a fair number
of users might not miss them if xyz-mode (which they do use) takes up
either of the sequences.

Don't you think that's a suboptimal situation?  Yes, it may be that some
users never miss features.  Perhaps lots of users never use your project
features because they have already bound C-x p to something else.

There are tradeoffs in any decision.

Freeing 'C-z' up, for example, won't help most authors anyway.

Equally well though, users may miss out on something that they would
have found useful.

I think it's better to do something about future collision up-front, to
deal with them *before* more happen.

I have some doubts that we'll be able to free up nice enough key bindings that third-party packages will all want to use.

And even if that happens, collisions between externally maintained packages can happen just as well. There is no foolproof solution.

Knowing the ecosystem and being considerate toward the existing players can go a long way, though.

Initiatives like xref (where you take an aspect of the UI and make it customizable, but keep the key bindings the same across the packages) can help too. Inferior modes and test runners could use the same treatment.



reply via email to

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