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

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2021-02-13 23:49]:
> 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.

Basically, the attempt to reserve some keys which were already in use
by third party packages did not work well and you participate in
mailing lists. Does Magit author participate too? As now it looks like
much attention is given to Magit but to me it looks like none of them
who are authors requested any favor from Emacs to reserve it for them.

I have just done M-x rgrep and found that many installed packages
simply suggest global key bindings, just few of them really bind it.

> 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.

That looks good as solution. Packages rather make the key maps and
then simple function could suggest few of key bindings and detect
which one is already bound to which keys and then suggest the menu or
choice where to place the prefix key.

Function could accept a list of various suggested prefix keys and then
verify each key if it is bound to something, and present the listing
let us say from 1 to 10 where keys are presented and displayed as
being bound. User can then choose to unbind specific key or use those
free keys as prefix for the package. If series of keys is not enough
at some point of time, new versions of the package could employ newer
or updated list.

(global-set-key-prefix-by-choice '("C-c p" "C-c o" "C-c j" "C-x x" "C-x /" 
"M-z"))

Then it could be presented as:

1. C-c p - free as prefix key, press [1] to select
2. C-c o - free as prefix key, press [2] to select
3. C-c j - free as prefix key, press [3] to select
4. C-x x - bound to `some-other-function', press [4] to select
5. C-x / - bound to `one-more-function', press [5] to select
6. M-z   - bound to `zap-to-chat', press [6] to select

Are you sure? Yes?

If you wish to customize the prefix key again for this package, run
M-x customize-prefix-for-package-X

> 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.

* Overview of noun moratorium

The noun moratorium has 2 senses (no senses from tagged texts)
1. moratorium -- (a legally authorized postponement before some obligation must 
be discharged)
2. moratorium -- (suspension of an ongoing activity)

So you suggest suspension of grabbing more keys? That sounds good idea
to me as well. There is no urgent need for that. That is why there are
reserved C-c keys, users can bind those new functions. If there is
some important function to be bound than that could or should be
solved with discussion.

> 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.

Maybe it will work the other way around, you start proposing to bind
more keys by default, maybe that can work better? I am not joking too
much. When pushing too much one thing in public space there is effect
that people may want the other thing (not being pushed one). Start
pushing the opposite, maybe that suddenly start working and keys stop
being bound.

> 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."

If I have understood it well, maybe I may be mistaken, but the
discussion to reserve the key yieled intentionall or not intentionally
with proposals to bind range of new keys. I am not sure if implemented
already, but I have seen the list. That is why, how about stop pushing
to bind keys and demand more bindings, maybe that causes less
bindings?

Jean