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

[Dmitry Gutov]

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.