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

[Jorge Javier Araya Navarro]

I unbound C-z in my config and use it for undo-fu (C-S-z for redo)

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

El domingo, 7 de febrero de 2021 a las 16:05, Gregory Heytings 
<gregory@heytings.org> escribió:

> =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"
>
> Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound to
>
> "suspend-frame", and "M-z M-z" to "zap-to-char"
>
> Option 3. C-o, with a single exception: "C-o C-o" would be bound to
>
> "open-line"
>
> Option 4. C-o and M-o, with two exceptions: "C-o C-o" would be bound to
>
> "open-line", and "M-o M-o" to "facemenu-keymap"
>
> =Rationale=
>
> 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].
>
> 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).
>
> 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.
>
> 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.
>
> =Limit=
>
> Conflicts are still possible, when two or more packages bind the same
>
> keys. These are, however, conflicts between packages, not between a
>
> package and Emacs, or between a package and users' personal
>
> configurations.
>
> Such conflicts are also less likely for typical users, who install a few
>
> packages each binding a few keys.
>
> 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.
>
> =Note=
>
> [1] These conventions were written 25 years ago, at a time when there were
>
> far fewer third-party packages, and have not changed substantially since
>
> them.