RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams <drew.adams@oracle.com>]

> > The current key binding conventions (see `(elisp) Key Binding
> > Conventions') reserve keys for users, for major modes and for
> > minor modes, but not for third-party packages.
> 
> In my understanding those third party packages usually define major or
> minor modes so the reservation of keys for third party packages is
> thus already supported that way.

The question is about reserving keys for 3rd-party
code so that _Emacs itself_ doesn't bind them by
default.  It's one thing for a 3rd-party library
to possibly conflict with another such.  It's a
different thing if Emacs suddenly binds keys by
default that the library has bound.

And no, there's no limitation that 3rd-party code
bind keys only in major- or minor-mode keymaps.

In general, it's more polite for 3rd-party code
not to bind global keys by default.  But it can,
and it sometimes does.  Use of a 3rd-party is
optional, just as turning on a major or minor
mode is optional.

> So I think there is no need to reserve more keys for third party
> packages. Finally, keys are limited.

The question is not about reserving keys
for 3rd-party use _from users_.  It's about
reserving them from Emacs itself, i.e., so
they don't become new _default_ bindings.

(And it can't be about reserving "more" keys
for 3rd-party code, as _NO_ keys are reserved
for them so far.)

There is no question about not allowing
_users_ to bind some keys.  Users can bind
or unbind ANY keys.  Always.

> many Emacs Lisp programmers became such due to fiddling with their
> configurations in the first place. That is positive impact, not a
> negative impact.

100%, yes.  (And maybe all, not just many.)

> > Reserving one key for third-party packages solves the above problems:

(No, it doesn't.)

> > third-party packages can automatically bind a few keys in that
> > reserved area, without conflicting with keys reserved for users and without
> > conflicting with future Emacs evolutions.
> 
> There are more than one keys reserved already in the manner you
> described such as those reserved for users can be proposed and used by
> third party packages, including those for minor and major modes, they
> can be used by third party packages. Solution is just there.

There are currently NO keys reserved for 3rd-party
code, so that Emacs itself won't bind them by default.

There is no question of reserving any keys from
users, so they can't use them.  Never has been,
never will be.

FWIW, I disagree with Gregory's proposal, which
is a scaled-down version of my proposal, which
is to reserve _ALL_ keys currently not bound by
default, for 3rd-parties to use.  He proposes to
reserve only one key for that.

IOW, I proposed that Emacs keep its mitts off
the few remaining top-level keys (which includes
top-level prefix keys).  We should at least have
a _moratorium_ on such grabbing by Emacs.

Gregory's reduction of my proposal is to reserve
only _one_ top-level key for 3rd-party use.
Emacs itself would be free to bind all the
remaining keys by default.  I oppose that, even
if someone will say that one is better than none.

> Reserving key for third party packages sounds limiting to me.
> They may have different preference than just one key.

Yes.  There are good reasons for any party: Emacs
itself, a 3rd-party, or a user, to want to use
any particular top-level key, including using it
as a prefix key.

> Recently I have learned how to define the prefix command...
> In my opinion that is great way of defining keys for third party
> packages. They could define the full key bindings list and let the
> user decide on the prefix key. They could propose some prefix key.
> It is one line in the configuration. It is something like:
> 
> (global-set-key (kbd "s-p") 'cf-map)

Exactly.  The binding can be optional (e.g. by
command or user option).  Or it can be provided
by default.

A user can easily move the whole set of keys on
that prefix key to another prefix key - or move
some, or none.

Grouping keys on a keymap is a great way to make
them available as a set.  And sometimes it makes
sense for a library to provide more than one set.

> which one do you like to use as prefix key for this third party
> package?
> Some question as above could help users quickly decide on a prefix and
> the line could be automatically inserted into the configuratio file.

Bookmark+ just has two user options, whose values
are lists of prefix keys.  (The value will usually
be a singleton list - just one prefix key, but if
you want more...)

`bmkp-bookmark-map-prefix-keys' - default: `C-x x'
`bmkp-jump-map-prefix-keys'     - default: `C-x j'

[But Emacs has just decided to usurp `C-x x' for
a default binding.  Previously, the Bookmark+
default was `C-x p', but then Emacs usurped that
for its Project library, so I changed to `C-x x'.
You get the picture - why 3rd-party code could
use a break from Emacs claiming more territory
for default bindings.]

You can set either option to nil to not have any
such prefix key.  And you can easily change to
different prefix keys.  You need not know anything
about how to create or bind prefix keys.