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

[Francis Belliveau <f.belliveau@comcast.net>]

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.
>