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

[Francis Belliveau]

I vote against the removal of the current C-o functionality.  I would not want 
to use two keystrokes where I currently use only one.
I expect that those that use emacs in terminal windows will also find the 
remapping of C-z a problem, but that is actually never done in the middle of 
file modification so I wold expect it to be less of a problem.

Overall, I expect that if a package has a number of functions it wishes to map, 
if should have a method that installs itself into a keymap of user choosing.  
Most packages do not need more than I few keys, although I have one that 
implements 15.  I put that behind M-o.

I do not know elisp enough to know if one can determine if a keystroke is a 
prefix key or not, but two functions could be implemented:
bind-keymap-to() and add-bindings-to-keymap() with appropriate prefixes and 
arguments of course.

A package that implements these two would allow a used to decide say:
    bind-keymap-to('C-o') and that would unbind C-o and convert it into a 
prefix key with empty keymap if it is not already a prefix key, then call the 
package's add-bindings-to-keymap('C-o').
Otherwise, if a user want to rebind a key that they already know is a prefix 
key, the can just call the "add-bindings" function.

Please do not tell me the syntax above is wrong since I expect that is it.  I 
only mean all that as a pseudo-code example.

The majority of the Rationale below is good, but it does not take into account 
the needs ot those who have decades of muscle-memory for high-speed editing 
that would get disrupted.  A command like "suspend" would never be used in an 
editing sequence, since it interrupts the edit session.  M-z and M-o are not 
keystrokes that I use, but I expect that those who do would have the same 
complaint with the remapping of "zap-to-char" thart I have with "open-line".  I 
cannot even guess why I would want a keystroke for "facemenu-keymap", but it 
sounds to me like it is already a prefix key.

BTW, your 25-years of history statement is inaccurate since I am sure that I 
have been using C-o since before 1990.


> On Feb 8, 2021, at 05:02, Gregory Heytings <gregory@heytings.org> wrote:
> 
> 
> [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"
> 
> 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.
>