RE: [External] : Re: Concern about new binding.

[Drew Adams]

> It seems to me that the root problem of this thread, and similar ones
> in
> the past months, is the lack of a convention for external packages in
> `(elisp) Key Binding Conventions'.  There is a convention for users,
> there
> are conventions for major and minor modes, but there is no convention
> for
> external packages such as Magit, Drew's packages, and so forth.

FWIW, I don't think that's the root problem of
this thread.  I don't even think it's much of
a problem.

I, for one, think that it makes sense for
3rd-party libraries to be in the same class as
users when it comes to key-binding conventions.

I might be convinced otherwise.  And yes, there
are differences among 3rd-party libraries.  Some
are huge and have many users.  Some are even
nearly part of Emacs itself.  Others are simply
some small bit of code that a user shares with
others.

I think that, until proven otherwise, we're OK
with lumping 3rd-party code with users, when it
comes to conventions about key bindings.

> Consequently, the only solution for such packages is to use the
> currently empty slots, with a sword of Damocles hanging over
> them: these empty slots could at any time be reclaimed by Emacs.
> I too can sympathize with Drew's (and other's) frustration when
> this happens.

It's indeed a problem.  The same problem can
arise if some other 3rd-party library decides
to use the same key (e.g. a prefix key) that
another library has long used.

But I think that such potential conflicts
among 3rd-party bindings are less of a problem
than Emacs itself grabbing keys.  (See above.
And again, I could be convinced otherwise.)

> A proposal to solve the current problem and future similar problems is
> to free one of the keys, and to mention in `(elisp) Key Binding
> Conventions' that it is, forever, reserved for external packages.

I'm not in favor of that - a single key for
all 3rd-party code.

> This proposal has two forms: a weak and a strong one.  The weak one
> would only reserve the control key, the strong one would also
> reserve the meta and control-meta keys.

I guess you mean not a single key but a
single key plus its Control or Control-&-Meta
modifiers?

I'm not in favor of that either - still too
limiting.

I favor allowing all keys that are currently
allowed for 3rd-party code.  And I favor Emacs
itself implementing a moratorium on binding any
more keys by default.

A moratorium that could be overruled in cases
deemed to be important, cases that would
hopefully be discussed here, and would of
course be decided by the maintainers.

> The candidate keys for that proposal are "z", "t" and "o".
> IOW, one could for example reserve either "C-z" (weak version), or "C-
> z"
> and "M-z" and "C-M-z" (strong version), for external packages.
> 
> This is a one-time change, which I'm sure will not be an easy one for
> everyone, but is a long-term solution that will avoid such repeated
> wars.

To me, that's too limiting for 3rd-party libraries.
I'd prefer what I say above.  Emacs itself should
keep its hands off new keys.

Emacs can instead repurpose some existing key
bindings, if it needs new bindings.  There are, I
think, some existing bindings that might not be
all that necessary.