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

[Drew Adams]

> > [Removed bugs@gnu.support from cc list.
> > Why was it included?]
> 
> That email address is Jean Louis, that's why it's there.  I find it
> confusing too.

Oh, sorry about that.  I thought it was maybe
some other mailing list.

> >> If a *general* moratorium isn't possible, then how about a more
> >> specific one?  How about applying it only to certain keymaps
> >> or prefix keys.
> >
> > We shouldn't assume from the get-go that a more
> > general hands-off isn't possible.
> >
> > (I know you said "if".  But Emacs devel _can_
> > sometimes be moved by what its users say they want.)
> 
> I'm not convinced that a totally general moratorium would be good.  For
> example, on this list a few days ago we talked about info-apropos.
> John Yates suggested binding it to a key in the C-h prefix.
> 
> I think something like that is fairly harmless.  Changing something two
> prefixes away is likely to affect nobody (e.g. C-x 8 1).

I agree that there are nuances, and that adding a key
to an already bound prefix key is less aggressive than
binding a top-level key by default.

Good point.  But let's at least start with a first-level
approximation.  The problem is not so much the kind of
thing you describe there.  The problem is things like
Emacs suddenly deciding to bind `C-x p', `C-x x', `C-x /'
etc. by default.

Details about possibly binding _any_ more keys by default
should be discussed generally, widely.  That's not been
done.  A general convention that Emacs should not do this
is in order, IMHO.  And I made clear that exceptions can
always be handled by good, general discussion followed by
maintainer decision.

It's not black & white.  There is a serious problem, and
I think there we should establish a general 
convention/rule/guideline/understanding that Emacs should
keep its mitts off keys not already bound.

As I pointed out, there's plenty of room for Emacs to
restructure existing default key bindings, to consolidate
using prefix keys or whatever.  And doing that can free
up keys both for new Emacs default bindings and 3rd-party
code.  For the former, I'm thinking along the lines you
mentioned - e.g. add a binding on some existing default
prefix key, while removing some global default key, i.e.,
move a command from a somewhat wasted default key to a
default prefix key.

Let Emacs restructure, to find keys it thinks it needs.
There's room for that.

Of course, doing that is hard work.  It requires and
invites the kind of my-key vs your-key discussion we've
now been seeing.  It's much _easier_ for Emacs to just
grab another virgin key.  But that's wrong - that's the
problem.