Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Jean Louis <bugs@gnu.support>]

* Gregory Heytings <gregory@heytings.org> [2021-02-14 00:19]:
> > > > Sorry for protracting the conversation, I just think the
> > > > interpretation of the guideline is important.
> > > 
> > > Not for the proposal itself.
> > 
> > Well yes, because if packages may bind to C-c *with* the consent of
> > users, the need for a special package map decreases.
> > 
> 
> As I said, IMO it does not, it can't work as a long-term solution, 26
> letters is simply not enough.  Anyway, neither I nor you can decide what the
> "correct" understanding of that guideline is, so I suggest we stop arguing.
> A proposal has been made, we'll see what the maintainers do with it.

C-c a - can be bound to single command

C-c a - can become prefix key for other 54 various commands like 26
        letters plus upper case letters = 52 plus 10 numbers = 62 + 32
        symbols = 94 various commands
C-c a a - can become as well prefix key for 94 various commands
C-c b a - can become as well prefix key for 94 various commands
etc.

It can work as long term solution.

Count all the combinations. It is far far more than 26 combinations. I
find that problem is already solved, just collisions with other key
bindings could be solved by built-in Emacs function where then third
party package invokes the built-in Emacs function to customize the
prefix for the package.

User then decides either to replace some already bound key or to use
some of the free keys. That is why we have programming and computer to
help us decide. Reading comments in packages or READMEs is one way,
but computer assisted decision is smarter way. We can use artificial
intelligence and `key-binding' function as help.

What I wonder is WHY is only one key suggested to be re-purposed? I
cannot see solution there, just more conflicts as then all packages
are going into one key.