RE: [External] : Re: not good proposal: "C-z <letter>" reserved for users

[Drew Adams <drew.adams@oracle.com>]

> >> I think that user-friendliness is beneficial.  It would help with
> >> that if packages could bind some keys by default.
> >
> > The current tradition is that a package provides a major or minor
> mode
> > (or several), puts one of them in their init file, and *those*
> install
> > some default keymaps.
> >
> > auto-mode-alist entries, however, can be added through autoloads.
> 
> 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).

To be clear, my understanding, from following bug
and emacs-devel threads, is as follows.  Anyone
can correct me if I'm mistaken in any way.

1. `C-x p' was recently grabbed as a prefix key
for Project (by Dmitry, in fact) - over my pleas
and arguments not to.  That was maybe 8 months ago?

Bookmark+ had, for many years, lots and lots of
keys on that prefix key.  The only arguments by
Dmitry in favor of grabbing that key for Project
were, in effect, (a) we want to do it and (b) we
don't need to care what Bookmark+ has been using.
OK.

As a result of that, I changed Bookmark+ last July
to use `C-x x' instead.  (There was no mention of
`C-x x' in that discussion, and it was unbound.)

2. Recently, Lars decided to bind `revert-buffer'
to `C-x x g'.  There was subsequent discussion
about using that prefix key `C-x x' for things
related to buffers, in general.  I don't know
exactly what's been done in that regard.

Needless to say, I again objected, saying that
I've moved Bookmark+ keys from prefix `C-x p' to
`C-x x', and asking that they not now usurp also
`C-x x'.  But AFAIK, `C-x x' has, yes, now been
grabbed by Emacs as a default global binding.

(There was quite a lot of objection, BTW, to the
idea that Emacs needs a _global_ key for reverting
a buffer.  I'm not even sure there was _anyone_
arguing in favor of that, besides the maintainer
who came up with the idea.)

3. There was talk in emacs-devel (or a bug thread?)
about binding `C-x /' by default.  I don't know
what finally happened in that regard.  But I chimed
in about that too, saying that I use that prefix key
for zones.el.  I mentioned this while pointing out
there is a _general_ problem here: Emacs grabbing
more keys for default bindings, leaving 3rd-party
code with fewer and fewer options.

4. I'll mention too that for Bookmark+ when I
changed from `C-x p' to `C-x x' I added a user
option for which key to use.  So users can deal
with the new conflict themselves, if I don't
end up trying yet another key as the default.

> The author of a third party package can't easily
> deal with that.  What if their minor mode used
> "C-x x"?  In that case it will remove the keymaps
> of a core feature (or the core feature will remove
> it's keymap).

Indeed.  And the anecdotal stories from me are
just that: one user's experience.  There's a long
history (future) in front of us.  This problem
will only become exacerbated.  The field of keys
that are not used by default Emacs is small and
dwindling.  And that, precisely at a time when the
development of 3rd-party libraries is growing.

We are no longer in the old Wild West days of a
vast, open new continent to colonize.

_Some_ solution is needed for this problem, which
will only increase.  _Because_ I objected recently,
raising this as a general problem, there has been
some discussion.  But the main Emacs maintainer has
declared that there is _no_ such problem.  End of
story, perhaps, but not, IMO, end of problem.

I proposed one possible solution - a _moratorium_
by Emacs from grabbing more keys by default.  Look
up the word "moratorium", if you aren't familiar
with it.

If you like, you can consider my proposal to be:
Let's at least STOP now from binding any more keys
by default, while we entertain discussion for other
possible solutions.  And as long as no adequate
solution, preferably somewhat consensual, is found,
Emacs just shouldn't bind more keys.  It can
repurpose keys that are already bound by default,
but it should stay away from binding new ones.

And I explicitly allowed for _exceptions_, to be
decided by the maintainers - after some general
discussion.  So IMO, this is not at all a radical
proposal.  It's essentially "STOP THE BLEEDING!"
as a _first step_.

> As Gregory Heyting has pointed out, what about
> packages that are not modes?  Not every package
> is a minor mode or major mode.

In fact, I'm pretty sure that most - maybe all -
libraries are not simply implementations of a mode.

Dealing with a mode, especially in terms of key
bindings, isn't really problematic.  Especially a
minor mode.  Sure, there can still be some key
conflicts, but that's nothing new.  Users juggle
multiple minor modes already.

> So, how should other types of package behave?
> 
> Lastly, the usability issue is still there.
> I think beginners find this kind of thing difficult.
> These days there are lots of Emacs "starter kits"
> that claim to make Emacs simpler.  A lot of what
> they do is configuring third-party packages.
> 
> Philip Kaludercic suggested some code for prompting
> users before mapping keys.  I think that's a good idea.

Maybe that could be part of a solution.  But many
users will not appreciate, or not be prepared for,
making such key-binding decisions at the outset and
on the fly.  And prompting would likely be in some
order, e.g., the first package loaded would prompt
first, or the first prompt would occur when the
first key conflict is detected.

There are lots of details and things to consider.
But I'm glad that at least some people are seriously
considering the problem and starting to think about
it.

Unfortunately, the main threads in emacs-devel about
this, kind of got hijacked by interjecting the
possibility of changing some existing Emacs default
key bindings.  I specifically wanted to avoid that,
or rather, to move that to a parallel, and longer
discussion.

I really would like to see us, FIRST, stop the
bleeding by agreeing that Emacs should stop binding
default keys while we figure things out and, SECOND,
start discussing solutions in parallel, with less
urgency, carefully.  And that discussion can, yes,
consider particular _existing_ key bindings and
possibilities of refactoring Emacs default key
bindings.

But the first step should be to agree to stop the
bleeding: "Emacs: hands-off new default keys, please."