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

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-08 19:38]:
> 
> [S Boucher apparently intended to reply to the following proposal sent on
> emacs-devel.]
> 
> =Proposal=
> 
> It is proposed to repurpose one key, and to reserve it in the key binding
> conventions for third-party packages.  The keys that could be reserved for
> that purpose are:
> 
> Option 1. C-z, with a single exception: "C-z C-z" would be bound to
> "suspend-frame"

Please consider that C-z is internationally vague and could cause some
inconveniences, as "z" is not always on the place where one think it
should be, it is often replaced with "y" on international
keyboards. It breaks some muscle memories.

I would not change C-z on terminal to nothing else but the long term
historical default.

> Option 3. C-o, with a single exception: "C-o C-o" would be bound to
> "open-line"

That would be so detrimental to remove C-o to do something else but
`open-line' function.

> 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 [1].

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.

There are many commands and it may be better to tell third party
packages to advise user how to bind keys or to propose to users the
key bindings and how it would otherwise change existing key
bindings. That is not so hard really. It could be just one screen with
questions when user invokes the package first time.

For example, Org agenda keybindings was proposed to me, now I do not
know by which party, but I got used to their proposal. Even though I
do not use agenda, it is bound on {C-c a}. The proposal was in
accordance with the key binding convention. So it looks just fine and
clear.

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

> When such packages need to bind a command to a key, they can (1) either
> suggest users to bind it to a key reserved for users (for example, org-mode
> suggests to globally bind "C-c c" to org-capture), or (2) bind it to a key
> currently unused by Emacs (for example, Magit binds "C-x g" to magit-status
> in buffers visiting a file in a Git repository).

That is good way to go.

> Neither of these solutions are optimal: (1) requires an explicit
> configuration by the user, something which might confuse newcomers, and
> which other users might not want to do because they already use the keys
> reserved for users for other purposes, and (2) might conflict with the
> evolution of Emacs when one or more commands are bound to a yet
> unused key.

Yes, I would like myself that Emacs is optimal and very ready for
newcomers, but it is not.

"Emacs is the advanced, extensible, customizable, self-documenting
editor."

Emacs is advanced, thus not a simple editor. It is for beginners and
advanced users, as advanced users would never become advanced if they
were never beginners. But those beginners would never become advanced
if they are spared of configuring Emacs. Let us not forget that many
Emacs Lisp programmers became such due to fiddling with their
configurations in the first place. That is positive impact, not a
negative impact. We want people to learn programming. Programming is
confusing when one enters into the subject. And so is the subject of
computing and any other subject. That is the learning path.

That is why I think that (1) and (2) is not not optimal, it is state
of Emacs. Developers and contributors are making it newcomer friendly,
and that is never ending process and never completed, and never will
be. That is the state of Emacs.

These conversations also show that there will never be an optimal
state, there can be some consensus or approval by some users, but
never an optimal state.

> Reserving one key for third-party packages solves the above problems:
> 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.

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

Recently I have learned how to define the prefix command:

(define-prefix-command 'cf-map)
(global-set-key (kbd "s-p") 'cf-map) ;; By changing this one, one can
                                     ;; move all subsequent keys to
                                     ;; different prefix
                                     
(define-key cf-map "F" #'cf-find-files-of-person)
(define-key cf-map "L" #'cf-tabulated-last-people)
(define-key cf-map "l" #'cf-tabulated-people-of-account)
(define-key cf-map "a" #'cf-account-helm)
(define-key cf-map "d" #'cf-people-by-description)
(define-key cf-map "f" #'cf-follow-up)
(define-key cf-map "i" #'cf-people-by-interactions)
(define-key cf-map "m" #'cf-people-by-mark-new)
(define-key cf-map "n" #'cf-create-contact)

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)

Or

(global-set-key (kbd "C-c") 'cf-map)

or similar.

As not to confuse users programmer may invoke a wizard question:

"It is detected that you could use following prefix keys for third
party package:

s-p (Super/Hyper key may have Windows logo on Windows keyboards)

C-.

C-,

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.

Otherwise, simple explanation and advise to user how to place the
configuration line is also minimizing any confusions. 

> Finally, such conflicts can be dealt with without confusing users too much:
> a package could automatically choose fallback key bindings when the
> preferred ones are already used by another package, and/or issue a warning
> to the user that they need to bind its commands manually.

Good idea. So those packages could even now automatically do
that as there are many keys available.

In general I just think that more marketing is required to package
authors on how to prepare key bindings and let users decide on it.

Maybe one could make a package that changes the prefix key or various
packages or the package that could "see" which packages are used and
which of them need positioning of their prefix keys. Then such package
could ask user with proposal:

- C-c bind prefix key for Org functions

- C-, bind prefix for Magit functions

Approve or change above y/n?


Jean