Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Jean Louis <bugs@gnu.support>]

* Gregory Heytings <gregory@heytings.org> [2021-02-13 00:49]:
> And that doesn't solve the problem that 26 letter keys is a small number.
> Yes, you can also use capital letters, and yes, you can put keymaps on these
> 26 letters instead of single commands.  IMO, that can't work as a long-term
> solution; if it were, it would already be used, and the fact is that it
> isn't, and that third-party packages prefer to use, or recommend to use,
> keys that are not yet bound by Emacs.

I see that combination already as huge one. I have my own packages
bound to prefix keys and I do use capital letters too like small
letter "l" in combination {C-c p l} I use to list people of certain
group but {C-c p L} I use to list all the recently entered people in
the database. Additionally to letters there are also various symbols,
so there are a lot of combinations. Then we have:

C-c LETTER (26 or more on international keyboards) x 2 (for capital letters) + number of symbols

than that is maybe approximately 60-70 keys, and if some of keys are
used as prefixes then we have 60 x 60 = 3600 possible keys roughly
estimated. Then if we add Super key to it, it becomes more than 7000
possible keys, if not 7500 or more.

Isn't that quite enough?

Then if third party package defines keys they could just say to user
"bind the map to any key you wish, we recommend C-c g" and the 40
commands used by third party package may be invoked by using C-c g
LETTER/SYMBOL

> Again: this, to reserve prefix key(s) for third-party packages, and only
> this, is what the proposal is about.

I think the proposal should say that reservation is meant for global
bindings by third party packages.

After consideration of many details I think that proposal is there to
solve specific problem, but that problem may not be solved anyway and
there are already various solutions to that problem even without the
proposal.

For example Magit did bind some keys and it works. There is no
problem. Those users who wish to change some keys they can adapt
little or replace some keys. But I don't think that proposal comes
from Magit developers, does it? So the solutions to that problem are
already in existence how I understand it.

Suggesting a prefix key to be bound by user on some of users' reserved
key is another solution as well.

In my opinion the number of possible keys is already over 7000,
probably even 10000 and more. Emacs would not so quickly use those
keys for itself.

For example none of Super key bindings is used by Emacs. That makes
alone possibly 7000-10000 possible combinations.

Reserving a key or keys by Emacs for general unknown third party
package would also require that there is some kind of a database of
reserved keys for various third party packages and such does not
exist. Similarly for /package or slash package enthusiasts which I am
one of them, there exists database of allocated package names:
https://cr.yp.to/slashpackage/list.html but in Emacs we do not have
the database of allocated key bindings for third party packages. So
third party packages may do anyway what they wish and want. Reserving
the key does not solve the randomity of plethora of combinations that
third party packages can invent and do, they may collide with each
other, they may use unused or used keys, combinations are too many.

Those who did understand conventions they did their best and already
provided solutions.

The solution should come from third party package in consensus with
the user who does the installation.

Solution to third party packages should not come from Emacs, as that
is what they are: third parties.

Then if we reserve let us say M-z for third party packages, then one
package will say I wish {M-z m} for command X, other package will say
they wish {M-z m} or command Y, so there is no benefit, again we have
numerous possible imaginary problems where there are no practical
problems. Solution to the problem of how third parties want to
function cannot possibly come from Emacs. Additionally third parties
are not controlled by Emacs development, they have zero obligation to
listen or to comply to it.

Those who do listen and comply will not have the database of allocated
key bindings and will have possible collision with other third party
packages. 

After the reservation of the key for third party package, then who is
to make the effort to inform all the thousands of developers of the
reservation? Reservation for packages requires informing people of
those reservations. Why would they comply? Emacs development is not
dictating how third parties should set their bindings.

We have seen here that users set their key bindings just how they
wish, somebody may remove C-o completely for something else, somebody
protests against this.

The pattern of key bindings by users is capricious. That is what we
can learn from discussion and the same capricious pattern is there
with third party packages.

Who would guarantee that third party packages would now use those
reserved keys and not set globally anyway otherwise reserved keys?

All for thinking.

Jean