[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
From: |
Robin Tarsiger |
Subject: |
Re: PROPOSAL: Repurpose one key and reserve it for third-party packages |
Date: |
Sun, 7 Feb 2021 22:52:53 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 |
Gregory Heytings wrote:
> 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"
In my own init code, I use f8 as a prefix key for a bunch of custom bindings,
including for global Calc, SLIME, and Org commands. This seems similar in
general
nature to the desired use for third-party packages, and I notice that f5--f8 are
all available in vanilla Emacs. That would obviously be less disruptive than
repurposing an existing key, but I don't know how reachable those keys are in
everyone's configurations.
For those who use them, M-z and C-o are frequent in normal editing. C-z
potentially
less so, but I don't really know that---I would expect it to be more redundant
in
GUI Emacs where there is usually a window manager gesture for iconify/deiconify,
but in TTY Emacs it's a necessity; but C-x C-z also exists and indeed parallels
C-x C-c better than C-z currently does. ("Preserve the normal behavior of
control
keys" is already out the window from C-c being a prefix, though of course that
doesn't obviate the "users may need to retrain" difficulty with any of these.)
I don't find M-o very useful currently because most modes don't preserve faces
meaningfully, and it's already a prefix key, but that idea feels really weird
for
some reason.
I _kind of_ like this general idea because the current situation is getting
kind of
hazardous. _But_ if any of these do happen, make sure the symbol for the
sub-keymap
is exposed so the user can move the whole thing somewhere else from init code.
-RTT
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, (continued)
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Thibaut Verron, 2021/02/08
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Stefan Kangas, 2021/02/08
- RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Drew Adams, 2021/02/08
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Simen Heggestøyl, 2021/02/09
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Juri Linkov, 2021/02/09
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/09
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/08
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Richard Stallman, 2021/02/09
Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Alan Mackenzie, 2021/02/08
Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/08
Re: PROPOSAL: Repurpose one key and reserve it for third-party packages,
Robin Tarsiger <=
Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Stefan Monnier, 2021/02/08
Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Dmitry Gutov, 2021/02/08