* PROPOSAL: Repurpose one key and reserve it for third-party packages
@ 2021-02-08 10:02 Gregory Heytings
2021-02-08 16:41 ` Emanuel Berg via Users list for the GNU Emacs text editor
` (3 more replies)
0 siblings, 4 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-08 10:02 UTC (permalink / raw)
To: help-gnu-emacs
[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.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 10:02 PROPOSAL: Repurpose one key and reserve it for third-party packages Gregory Heytings
@ 2021-02-08 16:41 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-08 22:01 ` Francis Belliveau
` (2 subsequent siblings)
3 siblings, 0 replies; 160+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-02-08 16:41 UTC (permalink / raw)
To: help-gnu-emacs
Gregory Heytings wrote:
> It is proposed to repurpose one key, and to reserve it in
> the key binding conventions for third-party packages.
This rings a bell, isn't there such a key/keystroke already?
--
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 10:02 PROPOSAL: Repurpose one key and reserve it for third-party packages Gregory Heytings
2021-02-08 16:41 ` Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-02-08 22:01 ` Francis Belliveau
2021-02-09 0:05 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-09 6:31 ` Jean Louis
2021-02-09 8:13 ` Marcin Borkowski
3 siblings, 1 reply; 160+ messages in thread
From: Francis Belliveau @ 2021-02-08 22:01 UTC (permalink / raw)
To: Gregory Heytings; +Cc: help-gnu-emacs
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.
>
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 22:01 ` Francis Belliveau
@ 2021-02-09 0:05 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-09 8:36 ` "Windows" key [was: Repurpose one key and reserve it for third-party] packages tomas
2021-02-10 22:54 ` PROPOSAL: Repurpose one key and reserve it for third-party packages Francis Belliveau
0 siblings, 2 replies; 160+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-02-09 0:05 UTC (permalink / raw)
To: help-gnu-emacs
Francis Belliveau wrote:
> 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. [...]
What about the Windows key, should we keep that or remove that
as well?
--
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 160+ messages in thread
* "Windows" key [was: Repurpose one key and reserve it for third-party] packages
2021-02-09 0:05 ` Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-02-09 8:36 ` tomas
2021-02-10 22:54 ` PROPOSAL: Repurpose one key and reserve it for third-party packages Francis Belliveau
1 sibling, 0 replies; 160+ messages in thread
From: tomas @ 2021-02-09 8:36 UTC (permalink / raw)
To: help-gnu-emacs
[-- Attachment #1: Type: text/plain, Size: 738 bytes --]
On Tue, Feb 09, 2021 at 01:05:22AM +0100, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> Francis Belliveau wrote:
>
> > 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. [...]
>
> What about the Windows key, should we keep that or remove that
> as well?
In my setup, the Windows key is bound to... window manager commands
(well, duh ;-)
I still don't know what to do with its right symmetrical sister
(labelled "print", but my evil plan is to turn it into a modifier,
too). I thought it'd reserved for Emacs, but I still hesitate to
open up one more key dumpster. So I'm still pondering :-)
Cheers
- t
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 0:05 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-09 8:36 ` "Windows" key [was: Repurpose one key and reserve it for third-party] packages tomas
@ 2021-02-10 22:54 ` Francis Belliveau
1 sibling, 0 replies; 160+ messages in thread
From: Francis Belliveau @ 2021-02-10 22:54 UTC (permalink / raw)
To: Emanuel Berg; +Cc: help-gnu-emacs
What Windows key?
C-o does "open-line" for me. It has nothing to do with Windows" and I know of no such function.
> On Feb 8, 2021, at 19:05, Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>
> Francis Belliveau wrote:
>
>> 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. [...]
>
> What about the Windows key, should we keep that or remove that
> as well?
>
> --
> underground experts united
> http://user.it.uu.se/~embe8573
> https://dataswamp.org/~incal
>
>
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 10:02 PROPOSAL: Repurpose one key and reserve it for third-party packages Gregory Heytings
2021-02-08 16:41 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-08 22:01 ` Francis Belliveau
@ 2021-02-09 6:31 ` Jean Louis
2021-02-09 9:13 ` Gregory Heytings
2021-02-09 17:13 ` [External] : " Drew Adams
2021-02-09 8:13 ` Marcin Borkowski
3 siblings, 2 replies; 160+ messages in thread
From: Jean Louis @ 2021-02-09 6:31 UTC (permalink / raw)
To: Gregory Heytings; +Cc: help-gnu-emacs
* 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
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 6:31 ` Jean Louis
@ 2021-02-09 9:13 ` Gregory Heytings
2021-02-10 11:17 ` Jean Louis
2021-02-09 17:13 ` [External] : " Drew Adams
1 sibling, 1 reply; 160+ messages in thread
From: Gregory Heytings @ 2021-02-09 9:13 UTC (permalink / raw)
To: Jean Louis; +Cc: help-gnu-emacs
>> 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.
>
That's not correct, many packages (not all of them, but many) implement
commands that are intended to be globally bound. The "org-capture"
command is an example. A package implementing advance bookmark commands
is another one, a packages implementing a dictionary search command is yet
another one.
>
> 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.
>
Third-party packages cannot do that, and they do not do that. A
third-party package cannot bind a key C-c LETTER key, it can at best
advise its users to do so. It's what Org-mode does.
>
> 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?
>
The first question is not an allowed one, C-c can only be used by users.
The second question is not a good one, C-, cannot be used in terminals.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 9:13 ` Gregory Heytings
@ 2021-02-10 11:17 ` Jean Louis
0 siblings, 0 replies; 160+ messages in thread
From: Jean Louis @ 2021-02-10 11:17 UTC (permalink / raw)
To: Gregory Heytings; +Cc: help-gnu-emacs
* Gregory Heytings <gregory@heytings.org> [2021-02-09 12:18]:
>
> > > 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.
> >
>
> That's not correct, many packages (not all of them, but many) implement
> commands that are intended to be globally bound. The "org-capture" command
> is an example. A package implementing advance bookmark commands is another
> one, a packages implementing a dictionary search command is yet
> another one.
Alright, but without reading the text below, I do not see here what is
not correct and how is your paragraph in any contradiction to my
quoted statement above. Maybe you know this technically better.
If I remember well org-capture suggested {C-c c} and I remember it was
suggested to me to place this line in the init.el:
(global-set-key "\C-cc" 'org-capture)
so I did so. This is all in alignment with what I meant, maybe I have
not expressed me well, and is in alignment on what you said.
Package authors may then research which key could be best and give
suggestions, but they will normally not bind it for user.
Then they give suggestions in accordance with the reserved key bindings.
> > 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.
>
> Third-party packages cannot do that, and they do not do that. A third-party
> package cannot bind a key C-c LETTER key, it can at best advise its users to
> do so. It's what Org-mode does.
That is what I also meant. I do not see disagreements, but you see. It
is interesting.
> > 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?
> >
>
> The first question is not an allowed one, C-c can only be used by
> users.
OK but I do not see disagreement:
- when text message in the package proposes to user to bind C-c c for
org-capture that is proposal and user can decide if to accept it or
not
- package could ask user to insert such configuration. Computer
software should be smarter than it is today. Users still need to do
a lot of work. Little more artificial intelligence is needed.
- dedicated imaginary package could manage and help users with
placement of keys and collisions between packages. I would regard
that as artificial intelligence.
> The second question is not a good one, C-, cannot be used in terminals.
That was an example. It was not meant to be 2 choices, it was not
meant to be those keys specifically, artificial intelligence program
would find out possible choices and have maybe some "mind" of most
popular packages and could help user with choices and let user make
decisions. Such program would recognize which key bindings could be
possibly bound and ask user to bind it conveniently but which exact
key bindings would be offered would be left to the algorithm.
Jean
^ permalink raw reply [flat|nested] 160+ messages in thread
* RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 6:31 ` Jean Louis
2021-02-09 9:13 ` Gregory Heytings
@ 2021-02-09 17:13 ` Drew Adams
2021-02-09 17:49 ` Gregory Heytings
2021-02-10 11:30 ` Jean Louis
1 sibling, 2 replies; 160+ messages in thread
From: Drew Adams @ 2021-02-09 17:13 UTC (permalink / raw)
To: Jean Louis, Gregory Heytings; +Cc: help-gnu-emacs@gnu.org
> > 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.
>
> 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.
The question is about reserving keys for 3rd-party
code so that _Emacs itself_ doesn't bind them by
default. It's one thing for a 3rd-party library
to possibly conflict with another such. It's a
different thing if Emacs suddenly binds keys by
default that the library has bound.
And no, there's no limitation that 3rd-party code
bind keys only in major- or minor-mode keymaps.
In general, it's more polite for 3rd-party code
not to bind global keys by default. But it can,
and it sometimes does. Use of a 3rd-party is
optional, just as turning on a major or minor
mode is optional.
> So I think there is no need to reserve more keys for third party
> packages. Finally, keys are limited.
The question is not about reserving keys
for 3rd-party use _from users_. It's about
reserving them from Emacs itself, i.e., so
they don't become new _default_ bindings.
(And it can't be about reserving "more" keys
for 3rd-party code, as _NO_ keys are reserved
for them so far.)
There is no question about not allowing
_users_ to bind some keys. Users can bind
or unbind ANY keys. Always.
> many Emacs Lisp programmers became such due to fiddling with their
> configurations in the first place. That is positive impact, not a
> negative impact.
100%, yes. (And maybe all, not just many.)
> > Reserving one key for third-party packages solves the above problems:
(No, it doesn't.)
> > 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.
There are currently NO keys reserved for 3rd-party
code, so that Emacs itself won't bind them by default.
There is no question of reserving any keys from
users, so they can't use them. Never has been,
never will be.
FWIW, I disagree with Gregory's proposal, which
is a scaled-down version of my proposal, which
is to reserve _ALL_ keys currently not bound by
default, for 3rd-parties to use. He proposes to
reserve only one key for that.
IOW, I proposed that Emacs keep its mitts off
the few remaining top-level keys (which includes
top-level prefix keys). We should at least have
a _moratorium_ on such grabbing by Emacs.
Gregory's reduction of my proposal is to reserve
only _one_ top-level key for 3rd-party use.
Emacs itself would be free to bind all the
remaining keys by default. I oppose that, even
if someone will say that one is better than none.
> Reserving key for third party packages sounds limiting to me.
> They may have different preference than just one key.
Yes. There are good reasons for any party: Emacs
itself, a 3rd-party, or a user, to want to use
any particular top-level key, including using it
as a prefix key.
> Recently I have learned how to define the prefix command...
> 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)
Exactly. The binding can be optional (e.g. by
command or user option). Or it can be provided
by default.
A user can easily move the whole set of keys on
that prefix key to another prefix key - or move
some, or none.
Grouping keys on a keymap is a great way to make
them available as a set. And sometimes it makes
sense for a library to provide more than one set.
> 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.
Bookmark+ just has two user options, whose values
are lists of prefix keys. (The value will usually
be a singleton list - just one prefix key, but if
you want more...)
`bmkp-bookmark-map-prefix-keys' - default: `C-x x'
`bmkp-jump-map-prefix-keys' - default: `C-x j'
[But Emacs has just decided to usurp `C-x x' for
a default binding. Previously, the Bookmark+
default was `C-x p', but then Emacs usurped that
for its Project library, so I changed to `C-x x'.
You get the picture - why 3rd-party code could
use a break from Emacs claiming more territory
for default bindings.]
You can set either option to nil to not have any
such prefix key. And you can easily change to
different prefix keys. You need not know anything
about how to create or bind prefix keys.
^ permalink raw reply [flat|nested] 160+ messages in thread
* RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 17:13 ` [External] : " Drew Adams
@ 2021-02-09 17:49 ` Gregory Heytings
2021-02-09 18:12 ` Drew Adams
2021-02-10 11:33 ` [External] : " Jean Louis
2021-02-10 11:30 ` Jean Louis
1 sibling, 2 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-09 17:49 UTC (permalink / raw)
To: Drew Adams; +Cc: help-gnu-emacs
>
> FWIW, I disagree with Gregory's proposal, which is a scaled-down version
> of my proposal, which is to reserve _ALL_ keys currently not bound by
> default, for 3rd-parties to use. He proposes to reserve only one key
> for that.
>
That's not the proposal, that's the way you look at the proposal. The
proposal is to free one or two keys, and to reserve them for third-party
libraries. Freeing one or two keys is (would be) an effort from the
viewpoint of Emacs, which would give more freedom to both Emacs (to use
the other keys as it wishes) and to third-party libraries (to use these
keys as they wish).
Your proposal, "to reserve _ALL_ keys currently not bound by default", has
I fear no chance whatsoever to be adopted. Emacs evolves, and deciding
that it cannot bind any new key from now on would be an arbitrary
constraint that would impair its evolution.
^ permalink raw reply [flat|nested] 160+ messages in thread
* RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 17:49 ` Gregory Heytings
@ 2021-02-09 18:12 ` Drew Adams
2021-02-09 19:23 ` Gregory Heytings
2021-02-10 11:33 ` [External] : " Jean Louis
1 sibling, 1 reply; 160+ messages in thread
From: Drew Adams @ 2021-02-09 18:12 UTC (permalink / raw)
To: Gregory Heytings; +Cc: help-gnu-emacs@gnu.org
> > FWIW, I disagree with Gregory's proposal, which is a scaled-down
> > version of my proposal, which is to reserve _ALL_ keys currently
> > not bound by default, for 3rd-parties to use. He proposes to
> > reserve only one key for that.
>
> That's not the proposal, that's the way you look at
> the proposal. The proposal is to free one or two keys,
You clearly said _one_ key, many times. Glad to
hear now that it's two keys (or at least "1 or 2").
> and to reserve them for third-party libraries. Freeing one or two
> keys is (would be) an effort from the viewpoint of Emacs,
Not if they're currently not bound by default.
Those are the keys I spoke of: keys not already
bound by default.
> which would give more freedom to both Emacs (to use the other
> keys as it wishes)
Emacs already has that freedom. And it's using
it more and more, narrowing the set of keys not
bound by default. It's getting pretty tight.
In the last year I've had to move a prefix key
I use _twice_ now.
> and to third-party libraries (to use these
> keys as they wish).
> Your proposal, "to reserve _ALL_ keys currently not
> bound by default", has I fear no chance whatsoever
> to be adopted.
It certainly has no chance if it's not even
proposed. And your immediate subsequent
pull-back proposal hasn't helped.
> Emacs evolves, and deciding that it cannot bind any
> new key from now on would be an arbitrary
> constraint that would impair its evolution.
1. I proposed a _moratorium_.
2. I explicitly said that maintainers could override
it, and that it would be good to solicit discussion
before doing so.
Instead of designating some single prefix key as
reserved for 3rd-party use, why not just have
Emacs lay off binding keys by default for a while?
There are a bunch of keys still available, though
there's been more encroachment recently. My ask
is just to put up a sign, "Wilderness area, no
further development now, please". Your proposal
is to designate a tiny patch as the only area to
protect from development.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 18:12 ` Drew Adams
@ 2021-02-09 19:23 ` Gregory Heytings
2021-02-09 20:52 ` [External] : " Drew Adams
0 siblings, 1 reply; 160+ messages in thread
From: Gregory Heytings @ 2021-02-09 19:23 UTC (permalink / raw)
To: Drew Adams; +Cc: help-gnu-emacs
>> That's not the proposal, that's the way you look at the proposal. The
>> proposal is to free one or two keys,
>
> You clearly said _one_ key, many times. Glad to hear now that it's two
> keys (or at least "1 or 2").
>
>> and to reserve them for third-party libraries. Freeing one or two keys
>> is (would be) an effort from the viewpoint of Emacs,
>
> Not if they're currently not bound by default.
>
I wonder: did you actually read the proposal?
>> Your proposal, "to reserve _ALL_ keys currently not bound by default",
>> has I fear no chance whatsoever to be adopted.
>
> It certainly has no chance if it's not even proposed. And your
> immediate subsequent pull-back proposal hasn't helped.
>
I'm sorry to read you've seen it as a pull back. What I saw was that your
request was being ignored, and I tried to help with something more
constructive.
^ permalink raw reply [flat|nested] 160+ messages in thread
* RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 19:23 ` Gregory Heytings
@ 2021-02-09 20:52 ` Drew Adams
2021-02-09 21:15 ` Gregory Heytings
0 siblings, 1 reply; 160+ messages in thread
From: Drew Adams @ 2021-02-09 20:52 UTC (permalink / raw)
To: Gregory Heytings; +Cc: help-gnu-emacs@gnu.org
> >> That's not the proposal, that's the way you look at the proposal.
> >> The proposal is to free one or two keys,
> >
> > You clearly said _one_ key, many times. Glad to hear now that it's
> > two keys (or at least "1 or 2").
> >
> >> and to reserve them for third-party libraries. Freeing one or two
> >> keys is (would be) an effort from the viewpoint of Emacs,
> >
> > Not if they're currently not bound by default.
>
> I wonder: did you actually read the proposal?
Yes. There's no effort needed if all keys not
currently bound are explicitly freed from use
for default Emacs key bindings. A fortiori,
for just one or two of them.
Of _them_ - the unbound keys.
Of course if keys that are currently bound by
default are to be freed up then some adjustment
would need to be made. But no effort is needed
for keys not yet bound - zero, beyond documenting
the fact.
By proposing to free up keys already bound, you
create more effort than is needed (zero), and you
solicit just the kind of back-&-forth objections
that have ensued: this key vs that key: Which
ones should be freed for 3rd-party code? And
what if we switched this and that? Or we did
this instead? Or...?
The simple answer, as a starting point, is _none_
of those keys. Just free up keys that are not
yet taken, just say that Emacs won't take them.
Additional discussion about possibly freeing up
more keys, which are currently taken, is also
welcome, but it should be separate from staking
out, now, the currently unbound keys as reserved
for 3rd parties.
Additional discussion about possibly refactoring
Emacs key bindings is also welcome. And there
too I've participated. There are repeatable keys
whose bindings are currently wasted. There are
keys whose commands are not so useful or not so
commonly used. There are keys that would be
better off used as prefix keys. All of that is
ripe terrain for making keys more useful and
more available.
But all of that entails arguing about _changing_
existing keys, which as you well know is iffy,
risky territory.
My proposal is to separate any and all such
possible default key-binding _changes_ from the
simple act of declaring the keys so far unbound
by default to be reserved for 3rd-party code.
No default keys to relearn or fight over. Just
a declaration of a moratorium on using up the
remaining virgin keyspace territory.
> >> Your proposal, "to reserve _ALL_ keys currently
> >> not bound by default", has I fear no chance
> >> whatsoever to be adopted.
> >
> > It certainly has no chance if it's not even
> > proposed. And your immediate subsequent
> > pull-back proposal hasn't helped.
>
> I'm sorry to read you've seen it as a pull back.
> What I saw was that your request was being ignored,
> and I tried to help with something more constructive.
I would welcome any such support, if that really
is your intention.
It took decades just to get `transient-mark-mode'
turned on by default. Same thing for `font-lock-mode'.
I have no illusions about how difficult change is.
But there's no failing like not being willing to
propose something just because it looks hard to
get passed. There's no failing like giving up
without trying.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 20:52 ` [External] : " Drew Adams
@ 2021-02-09 21:15 ` Gregory Heytings
2021-02-09 21:47 ` [External] : " Drew Adams
2021-02-10 9:05 ` Robert Thorpe
0 siblings, 2 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-09 21:15 UTC (permalink / raw)
To: Drew Adams; +Cc: help-gnu-emacs
>
> But no effort is needed for keys not yet bound - zero, beyond
> documenting the fact.
>
The effort, or the absence of effort, is not the important point here.
The main point is freedom: give more freedom to both Emacs and third-party
libraries. And "documenting the fact that keys not yet bound cannot be
bound anymore" hinders Emacs' freedom. I know, you also said that
"exceptions would be possible with the approval of maintainers", but
that's precisely what happened with the new "C-x x" key, and you objected
anyway.
>
> My proposal is to separate any and all such possible default key-binding
> _changes_ from the simple act of declaring the keys so far unbound by
> default to be reserved for 3rd-party code.
>
That just can't happen, it would be a arbitrary constraint that would
impair Emacs' evolution, it would mean that hundreds of small or large
potential improvements would not be possible anymore.
>> I'm sorry to read you've seen it as a pull back. What I saw was that
>> your request was being ignored, and I tried to help with something more
>> constructive.
>
> I would welcome any such support, if that really is your intention.
>
FWIW, it was indeed really my intention. The proposal is an attempt to
find a reasonable middle ground that would give as much freedom as
possible to Emacs, as much freedom as possible to third-party library
developers, and without changing users' habits too much.
^ permalink raw reply [flat|nested] 160+ messages in thread
* RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 21:15 ` Gregory Heytings
@ 2021-02-09 21:47 ` Drew Adams
2021-02-09 22:06 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-10 11:07 ` Gregory Heytings
2021-02-10 9:05 ` Robert Thorpe
1 sibling, 2 replies; 160+ messages in thread
From: Drew Adams @ 2021-02-09 21:47 UTC (permalink / raw)
To: Gregory Heytings; +Cc: help-gnu-emacs@gnu.org
> > But no effort is needed for keys not yet bound
> > - zero, beyond documenting the fact.
>
> The effort, or the absence of effort, is not the
> important point here.
You're the one who brought up the "effort" needed
by Emacs to carry out this or that proposed change.
You claimed that your proposal needed less effort.
I argued that it needs more effort (> zero).
This was important enough that you brought it up.
Now it's not important. OK.
> The main point is freedom: give more freedom to both Emacs and third-
> party libraries. And "documenting the fact that keys not yet bound
> cannot be bound anymore" hinders Emacs' freedom. I know, you also said that
> "exceptions would be possible with the approval of maintainers", but
> that's precisely what happened with the new "C-x x" key, and you
> objected anyway.
Maintainers decide. I accept that - that's their
role, always, including on those occasions where
I might disagree.
The entire discussion was brought to emacs-devel
- not by me - from a bug thread, where `C-x x'
was taken over willy nilly, yes, over my objection.
And the bug/enhancement request was much narrower.
The decision was to bind a _global_ key by default.
Gigantic overkill, for the narrow problem raised
by the bug report.
I agreed (in emacs-devel, when discussed there,
and in the bug thread before that) that such wide
decisions - wider than the bug thread - should
preferably follow wider discussion in emacs-devel.
Half of the discussion in emacs-devel was/is about
this problem that some big, wide-ranging change
gets made in a bug thread, without many eyes seeing
it or minds discussing it. That's a problem (IMO
- the maintainers disagree).
Wrt the actual change made:
I objected that, within the last year, first prefix
key `C-x p' was taken over, so I changed my code
to use `C-x x' instead, and now `C-x x' was also
taken over. That's quite a bit to lose in a year.
And both changes were made in bug threads - no
discussion in emacs-devel.
I objected to that, and I still object. It's not
I who decide, and that's fine. But my opinion
that this isn't a good change, and that such things
should be discussed in emacs-devel, remains.
I'm not so worried as you about Emacs's "freedom"
to bind the keys it wants. Casting this as a
question of "freedom" is alarmist and ridiculous,
IMO. This is a question about what key-binding
conventions we should have, nothing more.
> > My proposal is to separate any and all such
> > possible default key-binding _changes_ from
> > the simple act of declaring the keys so far
> > unbound by default to be reserved for
> > 3rd-party code.
>
> That just can't happen, it would be a arbitrary constraint that would
> impair Emacs' evolution, it would mean that hundreds of small or large
> potential improvements would not be possible anymore.
Not at all. It would mean that Emacs would try
harder not to add new default key bindings. It's
not trying hard enough now - that's the problem.
IMO, it's gotten worse lately, when we can least
afford it (available keys are scarcer and scarcer).
I asked for other solutions to the problem (still
asking). And the maintainer's reply was that
there is no problem.
Yes, you proposed another answer to the problem,
and that's fine. It's not as good an answer as
mine, IMO, but at least you offered something.
> > I would welcome any such support, if that
> > really is your intention.
>
> FWIW, it was indeed really my intention. The proposal is an attempt to
> find a reasonable middle ground that would give as much freedom as
> possible to Emacs, as much freedom as possible to third-party library
> developers, and without changing users' habits too much.
That's a good intention, though the ideas that
this is about "freedom", and that Emacs needs
more "freedom" to add default key bindings,
are misguided, IMO.
And as I said, by proposing to use a currently
bound key for this you increase, not decrease,
the contention and argument over which keys
Emacs should "lose" to this, and you increase,
not decrease, the need for users to change habits.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 21:47 ` [External] : " Drew Adams
@ 2021-02-09 22:06 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-09 22:58 ` Drew Adams
2021-02-10 11:07 ` Gregory Heytings
1 sibling, 1 reply; 160+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-02-09 22:06 UTC (permalink / raw)
To: help-gnu-emacs
Drew Adams wrote:
>>> But no effort is needed for keys not yet bound - zero,
>>> beyond documenting the fact.
>>
>> The effort, or the absence of effort, is not the important
>> point here.
>
> You're the one who brought up the "effort" needed by Emacs
> to carry out this or that proposed change. You claimed that
> your proposal needed less effort. I argued that it needs
> more effort (> zero).
>
> This was important enough that you brought it up. Now it's
> not important. OK.
>
>> The main point is freedom: give more freedom to both Emacs
>> and third- party libraries. And "documenting the fact that
>> keys not yet bound cannot be bound anymore" hinders Emacs'
>> freedom. I know, you also said that "exceptions would be
>> possible with the approval of maintainers", but that's
>> precisely what happened with the new "C-x x" key, and you
>> objected anyway.
>
> Maintainers decide. I accept that - that's their role,
> always, including on those occasions where I might disagree.
>
> The entire discussion was brought to emacs-devel - not by me
> - from a bug thread, where `C-x x' was taken over willy
> nilly, yes, over my objection.
>
> And the bug/enhancement request was much narrower.
> The decision was to bind a _global_ key by default.
> Gigantic overkill, for the narrow problem raised by the
> bug report.
>
> I agreed (in emacs-devel, when discussed there, and in the
> bug thread before that) that such wide decisions - wider
> than the bug thread - should preferably follow wider
> discussion in emacs-devel.
>
> Half of the discussion in emacs-devel was/is about this
> problem that some big, wide-ranging change gets made in
> a bug thread, without many eyes seeing it or minds
> discussing it. That's a problem (IMO - the maintainers
> disagree).
>
> Wrt the actual change made:
>
> I objected that, within the last year, first prefix key `C-x
> p' was taken over, so I changed my code to use `C-x x'
> instead, and now `C-x x' was also taken over. That's quite
> a bit to lose in a year. And both changes were made in bug
> threads - no discussion in emacs-devel.
>
> I objected to that, and I still object. It's not I who
> decide, and that's fine. But my opinion that this isn't
> a good change, and that such things should be discussed in
> emacs-devel, remains.
>
> I'm not so worried as you about Emacs's "freedom" to bind
> the keys it wants. Casting this as a question of "freedom"
> is alarmist and ridiculous, IMO. This is a question about
> what key-binding conventions we should have, nothing more.
>
>>> My proposal is to separate any and all such possible
>>> default key-binding _changes_ from the simple act of
>>> declaring the keys so far unbound by default to be
>>> reserved for 3rd-party code.
>>
>> That just can't happen, it would be a arbitrary constraint
>> that would impair Emacs' evolution, it would mean that
>> hundreds of small or large potential improvements would not
>> be possible anymore.
>
> Not at all. It would mean that Emacs would try harder not to
> add new default key bindings. It's not trying hard enough
> now - that's the problem. IMO, it's gotten worse lately,
> when we can least afford it (available keys are scarcer and
> scarcer).
>
> I asked for other solutions to the problem (still asking).
> And the maintainer's reply was that there is no problem.
>
> Yes, you proposed another answer to the problem, and that's
> fine. It's not as good an answer as mine, IMO, but at least
> you offered something.
>
>>> I would welcome any such support, if that really is
>>> your intention.
>>
>> FWIW, it was indeed really my intention. The proposal is an
>> attempt to find a reasonable middle ground that would give
>> as much freedom as possible to Emacs, as much freedom as
>> possible to third-party library developers, and without
>> changing users' habits too much.
>
> That's a good intention, though the ideas that this is about
> "freedom", and that Emacs needs more "freedom" to add
> default key bindings, are misguided, IMO.
>
> And as I said, by proposing to use a currently bound key for
> this you increase, not decrease, the contention and argument
> over which keys Emacs should "lose" to this, and you
> increase, not decrease, the need for users to change habits.
If only you could be passionate about it!
But seriously now, I thought people had just got a bit crazy
like they sometimes do, but reading this long post I realize
I missed something... What has happened? Can anyone summarize
it i one or to paragraphs instead of ~20?
--
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 160+ messages in thread
* RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 22:06 ` Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-02-09 22:58 ` Drew Adams
2021-02-09 23:23 ` Drew Adams
2021-02-09 23:48 ` Emanuel Berg via Users list for the GNU Emacs text editor
0 siblings, 2 replies; 160+ messages in thread
From: Drew Adams @ 2021-02-09 22:58 UTC (permalink / raw)
To: Emanuel Berg; +Cc: Help-Gnu-Emacs (help-gnu-emacs@gnu.org)
> I realize I missed something... What has happened?
> Can anyone summarize it i one or to paragraphs
> instead of ~20?
Here's my summary (1-9). Others might see it
differently. And it's possible that I don't
remember some details perfectly. Someone will
correct me if I'm mistaken somewhere.
1. Bug #46151, "Set revert-buffer-function in shell
command output buffers", proposed binding a key for
`revert-buffer' in shell command buffers (only).
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46151
2. A discussion in that bug thread led to discussion
of whether Emacs needs a _global_ key binding for
`revert-buffer'.
My own opinion was this:
Overall, my opinion is to NOT bind it by default.
Yes, it's useful.
But it's also easy to do with `M-x revert'. (And
then repeat that as a previous command, as needed.)
And it has many existing bindings, for modes where
it's used frequently.
Some others agreed that we need no global binding
for `revert-buffer'. If interested, see the thread
for the discussion.
3. The bug-thread discussion then went toward binding it
to a global key under `C-x'. My position was not only
that we need no global binding for it, but that `C-x',
in particular, should at this point be left alone. I
explained that I already was forced to move from using
prefix key `C-x p' to `C-x x' etc. I said:
Users and 3rd-party libraries should really start to
take precedence now, IMHO. Emacs should try not to
bind any more keys by default - starting with `C-x'.
And certainly for things like `revert-buffer', which
have survived for 35 years without a default binding.
YAGNI.
4. Maintainer Lars bound `revert-buffer' globally to
`C-x g', and closed the shell buffer bug.
5. User Ergus posted in emacs-devel about that,
complaining that the question should have been
discussed in emacs-devel (the consequences are
wider than just shell buffers).
6. A long discussion ensued in emacs-devel. In
that discussion I agreed that when a bug-thread
discussion moves beyond the bug to wider questions
with wide consequences it should preferably be
moved to emacs-devel.
And I repeated my disagreement about globally
binding `revert-buffer', and in particular about
binding it to something on `C-x'. I repeated my
suggestion that Emacs desist for a while from
binding any new keys - at least that it try and
have that as a convention/goal, and that we
reserve those remaining keys for use by 3rd-party
libraries. Gregory proposed instead that we
just reserve one key under `C-x', for use as a
prefix key by 3rd-party code.
7. The main maintainer, Eli, disagreed that questions
wider than a bug's subject should generally be
brought to emacs-devel, and he supported the
decision to bind `revert-buffer' to `C-x g'.
Other users spoke up complaining about that key,
suggesting other keys for it, and so on. Each
time a key was suggested someone invariably
complained. (Not I - my disagreement is more
general - I would no global key to be bound to
it by default.)
8. There was also discussion about the problem of
people in emacs-devel not being aware of the
details of this or that bug report, IOW, _how_
to make the wider group be aware of some bug
discussion that's grown wider and should maybe
be moved to emacs-devel.
9. That's pretty much where we are, I think. Again,
I may have forgotten something here or there. I
haven't intentionally left anything out.
___
Here's the summary of my position, from that bug thread:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46151#88
And here's a longer post of mine about the various
questions - a summary, but not short.
https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg00312.html
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 21:47 ` [External] : " Drew Adams
2021-02-09 22:06 ` Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-02-10 11:07 ` Gregory Heytings
1 sibling, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-10 11:07 UTC (permalink / raw)
To: Drew Adams; +Cc: help-gnu-emacs
>>> My proposal is to separate any and all such possible default
>>> key-binding _changes_ from the simple act of declaring the keys so far
>>> unbound by default to be reserved for 3rd-party code.
>>
>> That just can't happen, it would be a arbitrary constraint that would
>> impair Emacs' evolution, it would mean that hundreds of small or large
>> potential improvements would not be possible anymore.
>
> Not at all. It would mean that Emacs would try harder not to add new
> default key bindings.
>
I see your point, but two maintainers clearly replied to your proposal and
said they will never agree with it. IMO it would be better to take that
as a postulate for further reflection.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 21:15 ` Gregory Heytings
2021-02-09 21:47 ` [External] : " Drew Adams
@ 2021-02-10 9:05 ` Robert Thorpe
2021-02-10 14:42 ` Emanuel Berg via Users list for the GNU Emacs text editor
1 sibling, 1 reply; 160+ messages in thread
From: Robert Thorpe @ 2021-02-10 9:05 UTC (permalink / raw)
To: help-gnu-emacs, Eli Zaretskii; +Cc: Gregory Heytings
Can someone tell me.... What exactly is this thread about? Is it a
formal request for input from the Emacs maintainers? I.e. is it like a
poll?
Or is it just a discussion about what they may do?
BR,
Robert Thorpe
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 9:05 ` Robert Thorpe
@ 2021-02-10 14:42 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-10 14:59 ` Gregory Heytings
0 siblings, 1 reply; 160+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-02-10 14:42 UTC (permalink / raw)
To: help-gnu-emacs
Robert Thorpe wrote:
> Can someone tell me.... What exactly is this thread about?
> Is it a formal request for input from the Emacs maintainers?
> I.e. is it like a poll?
>
> Or is it just a discussion about what they may do?
Ha :) I don't understand anything either.
And what do you mean "this thread", there are FOUR threads
about this, and probably additionally at enacs.devel and
emacs.bugs as well :)
Re: PROPOSAL: Repurpose one key and reserve it for
third-party packages
Re: not good proposal: "C-z <letter>" reserved for users
Re: Proposal: "C-z <letter>" reserved for users
Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
??? :)
--
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 14:42 ` Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-02-10 14:59 ` Gregory Heytings
0 siblings, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-10 14:59 UTC (permalink / raw)
To: Emanuel Berg; +Cc: help-gnu-emacs
>
> I don't understand anything either.
>
> And what do you mean "this thread", there are FOUR threads about
> this [...]
>
> Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
>
> Re: not good proposal: "C-z <letter>" reserved for users
>
> Re: Proposal: "C-z <letter>" reserved for users
>
> Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for
> third-party packages
>
What happened is that the "PROPOSAL: Repurpose one key..." thread was
started on emacs-devel, and a few hours later S Boucher started a parallel
thread with a similar subject but a different content on help-gnu-emacs.
This did not contribute to clarity indeed.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 17:49 ` Gregory Heytings
2021-02-09 18:12 ` Drew Adams
@ 2021-02-10 11:33 ` Jean Louis
2021-02-10 11:41 ` Thibaut Verron
1 sibling, 1 reply; 160+ messages in thread
From: Jean Louis @ 2021-02-10 11:33 UTC (permalink / raw)
To: Gregory Heytings; +Cc: help-gnu-emacs
* Gregory Heytings <gregory@heytings.org> [2021-02-09 20:50]:
>
> >
> > FWIW, I disagree with Gregory's proposal, which is a scaled-down version
> > of my proposal, which is to reserve _ALL_ keys currently not bound by
> > default, for 3rd-parties to use. He proposes to reserve only one key
> > for that.
> >
>
> That's not the proposal, that's the way you look at the proposal. The
> proposal is to free one or two keys, and to reserve them for third-party
> libraries. Freeing one or two keys is (would be) an effort from the
> viewpoint of Emacs, which would give more freedom to both Emacs (to use the
> other keys as it wishes) and to third-party libraries (to use these keys as
> they wish
Unbound key I found is M-n and there are those like M-[ M and M-]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 11:33 ` [External] : " Jean Louis
@ 2021-02-10 11:41 ` Thibaut Verron
2021-02-10 15:29 ` Eli Zaretskii
0 siblings, 1 reply; 160+ messages in thread
From: Thibaut Verron @ 2021-02-10 11:41 UTC (permalink / raw)
To: Gregory Heytings, Drew Adams, help-gnu-emacs
2021-02-10 12:33 UTC+01:00, Jean Louis <bugs@gnu.support>:
> * Gregory Heytings <gregory@heytings.org> [2021-02-09 20:50]:
>>
>> >
>> > FWIW, I disagree with Gregory's proposal, which is a scaled-down
>> > version
>> > of my proposal, which is to reserve _ALL_ keys currently not bound by
>> > default, for 3rd-parties to use. He proposes to reserve only one key
>> > for that.
>> >
>>
>> That's not the proposal, that's the way you look at the proposal. The
>> proposal is to free one or two keys, and to reserve them for third-party
>> libraries. Freeing one or two keys is (would be) an effort from the
>> viewpoint of Emacs, which would give more freedom to both Emacs (to use
>> the
>> other keys as it wishes) and to third-party libraries (to use these keys
>> as
>> they wish
>
> Unbound key I found is M-n and there are those like M-[ M and M-]
M-n (and its sister M-p) are used for navigating history in a lot of modes.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 11:41 ` Thibaut Verron
@ 2021-02-10 15:29 ` Eli Zaretskii
0 siblings, 0 replies; 160+ messages in thread
From: Eli Zaretskii @ 2021-02-10 15:29 UTC (permalink / raw)
To: thibaut.verron; +Cc: gregory, help-gnu-emacs
> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Wed, 10 Feb 2021 12:41:17 +0100
>
> M-n (and its sister M-p) are used for navigating history in a lot of modes.
Not just history; any mode where next/previous item makes sense. For
example, Rmail binds it to a command that shows the next email
message.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 17:13 ` [External] : " Drew Adams
2021-02-09 17:49 ` Gregory Heytings
@ 2021-02-10 11:30 ` Jean Louis
1 sibling, 0 replies; 160+ messages in thread
From: Jean Louis @ 2021-02-10 11:30 UTC (permalink / raw)
To: Drew Adams; +Cc: Gregory Heytings, help-gnu-emacs@gnu.org
* Drew Adams <drew.adams@oracle.com> [2021-02-09 20:14]:
> > So I think there is no need to reserve more keys for third party
> > packages. Finally, keys are limited.
>
> The question is not about reserving keys
> for 3rd-party use _from users_. It's about
> reserving them from Emacs itself, i.e., so
> they don't become new _default_ bindings.
Sure I understand that. The point from me was that those keys reserved
for users can be advised for use by third party packages just as the
Org mode does it. In my opinion there is no problem there. Org mode
suggests users to bind let us say {C-c c} for `org-capture' and so
many do. In the same way can do also other packages.
Such keys are then not bound by the package automatically but reserved
for users.
For example I do not mind pressing {C-x v v} for version control, so I
would not mind typing {C-c o KEY} for org related functions. Then
maybe piece of artificial intelligence or simple description in the
package would advise me to set `C-c o' as a prefix for org related
functions, and I would be set.
Then for magit I could set `C-c m' as magit related prefix and I could
use anything there like {C-c m g} or anything. Though I do not use
magit. It is example.
So maybe people discuss here about keys to be reserved for automated
bindings, to let the package authors decide which key to bind that
will not conflict with any of Emacs keys and none of user defined
keys.
I see that those keys reserved for users should be suggested by
packages. Like package could say "Use one of F5-F9 as prefix key for
Magit"
Using Super key like that key between Control and Aternative Control
that may have Windoze logo on it is very handy on X, but not so handy
in console. It may not work without special setups. If some automated
solution is found in Emacs for Super key to work in console the same
as in X, then that could be door to opening many new keys for
reservations.
General problem is that Emacs needs many keys. I would like having the
keyboard with more modifiers.
Jean
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 10:02 PROPOSAL: Repurpose one key and reserve it for third-party packages Gregory Heytings
` (2 preceding siblings ...)
2021-02-09 6:31 ` Jean Louis
@ 2021-02-09 8:13 ` Marcin Borkowski
2021-02-09 9:13 ` Gregory Heytings
3 siblings, 1 reply; 160+ messages in thread
From: Marcin Borkowski @ 2021-02-09 8:13 UTC (permalink / raw)
To: Gregory Heytings; +Cc: help-gnu-emacs
On 2021-02-08, at 11:02, Gregory Heytings <gregory@heytings.org> wrote:
> 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"
This I find surprising. M-z is *extremely* useful, why would anyone
want to delegate it to two-key sequence like M-z M-z?
Best,
--
Marcin Borkowski
http://mbork.pl
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 8:13 ` Marcin Borkowski
@ 2021-02-09 9:13 ` Gregory Heytings
0 siblings, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-09 9:13 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: help-gnu-emacs
>> 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"
>
> This I find surprising. M-z is *extremely* useful, why would anyone
> want to delegate it to two-key sequence like M-z M-z?
>
It's a proposal, meant to be discussed. Many said that they never use
M-z. That's of course not enough to move it somewhere else, but it means
that it could make sense. And if it's not a frequently used command,
pressing three keys instead of two is not that difficult.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
@ 2021-02-15 19:01 Gregory Heytings
2021-02-15 19:55 ` Dmitry Gutov
0 siblings, 1 reply; 160+ messages in thread
From: Gregory Heytings @ 2021-02-15 19:01 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: help-gnu-emacs
[Re-attaching this to another thread.]
>
> Freeing 'C-z' up, for example, won't help most authors anyway.
>
Why not? Could you perhaps elaborate?
>
> I have some doubts that we'll be able to free up nice enough key
> bindings that third-party packages will all want to use.
>
What would be, for you, a nice enough key binding?
>
> And even if that happens, collisions between externally maintained
> packages can happen just as well. There is no foolproof solution.
>
That's unavoidable, but still much better for newcomers than the current
situation. And there are ways to handle such collisions, which should be
rare if the number of available keys is large enough, in a user-friendly
way.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-15 19:01 Gregory Heytings
@ 2021-02-15 19:55 ` Dmitry Gutov
0 siblings, 0 replies; 160+ messages in thread
From: Dmitry Gutov @ 2021-02-15 19:55 UTC (permalink / raw)
To: Gregory Heytings; +Cc: help-gnu-emacs
On 15.02.2021 21:01, Gregory Heytings wrote:
>
> [Re-attaching this to another thread.]
>
>>
>> Freeing 'C-z' up, for example, won't help most authors anyway.
>>
>
> Why not? Could you perhaps elaborate?
In case it was not apparent from the preceding discussion: it's a
contentious binding, and even if I was not using it myself, I should
have been aware that a significant number of Emacs users already bind
that key in their init scripts (to 'undo' or 'undo-tree-undo', I mean).
Or use the default binding often, as some of the regulars here report.
As a package author, I would make an effort to choose a binding that is
more likely to be unoccupied in all my users' configs. Or be, you know,
free-able, which 'C-z' likely isn't.
>> I have some doubts that we'll be able to free up nice enough key
>> bindings that third-party packages will all want to use.
>>
>
> What would be, for you, a nice enough key binding?
Some examples:
- diff-hl adds some bindings under the 'C-x v' map because it is
intended as an extension of VC.
- company doesn't add any global bindings, but has a number of them
inside company-active-map (when completion is ongoing) and also
recommends the user choosew a binding for `company-complete`. I use
'C-/', personally.
- rspec-mode uses 'C-c ,' as the default keymap prefix but makes it
customizable via a variable.
- robe uses a number of bindings reminiscent of SLIME. These days I
should migrate some of them to the xref package, and the rest ('C-c C-d'
most prominently) keep as-is. Could have migrated to Eldoc, but that one
is moving in a weird direction lately.
>> And even if that happens, collisions between externally maintained
>> packages can happen just as well. There is no foolproof solution.
>>
>
> That's unavoidable, but still much better for newcomers than the current
> situation. And there are ways to handle such collisions, which should
> be rare if the number of available keys is large enough, in a
> user-friendly way.
FTR, I don't support the recent addition of bindings on 'C-x x', in part
because those commands don't seem essential to me. But for the same
reason I don't see a problem with any third-party mode continuing to use
'C-x x' as its keymap prefix.
^ permalink raw reply [flat|nested] 160+ messages in thread
* PROPOSAL: Repurpose one key and reserve it for third-party packages
@ 2021-02-07 22:05 Gregory Heytings
2021-02-08 0:13 ` Ergus
` (8 more replies)
0 siblings, 9 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-07 22:05 UTC (permalink / raw)
To: 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.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-07 22:05 Gregory Heytings
@ 2021-02-08 0:13 ` Ergus
2021-02-08 2:57 ` Jorge Javier Araya Navarro
` (7 subsequent siblings)
8 siblings, 0 replies; 160+ messages in thread
From: Ergus @ 2021-02-08 0:13 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
Hi Gregory:
IMO We shouldn't try to change C-o if we want an agreement. But all the
changes sound reasonable due to the current situation. In other editors
C-o is open file... just to say.
On Sun, Feb 07, 2021 at 10:05:50PM +0000, Gregory Heytings wrote:
>
>=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.
>
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-07 22:05 Gregory Heytings
2021-02-08 0:13 ` Ergus
@ 2021-02-08 2:57 ` Jorge Javier Araya Navarro
2021-02-08 3:46 ` Richard Stallman
` (6 subsequent siblings)
8 siblings, 0 replies; 160+ messages in thread
From: Jorge Javier Araya Navarro @ 2021-02-08 2:57 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-07 22:05 Gregory Heytings
2021-02-08 0:13 ` Ergus
2021-02-08 2:57 ` Jorge Javier Araya Navarro
@ 2021-02-08 3:46 ` Richard Stallman
2021-02-08 7:20 ` Stefan Kangas
` (2 more replies)
2021-02-08 4:52 ` Robin Tarsiger
` (5 subsequent siblings)
8 siblings, 3 replies; 160+ messages in thread
From: Richard Stallman @ 2021-02-08 3:46 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Option 1. C-z, with a single exception: "C-z C-z" would be bound to
> "suspend-frame"
I think that these changes for C-z, M-z and C-o would be a big pain in
the neck.
However, it would be possible to make M-z M-ANYTHING available for
other bindings and reserve them for whatever we wish. That would not
conflict with the current meaning of M-z, because meta characters
can't be in the buffer.
The binding of M-m is less useful than many other keys.
Perhaps it could be given to some other use.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 3:46 ` Richard Stallman
@ 2021-02-08 7:20 ` Stefan Kangas
2021-02-08 14:58 ` Lars Ingebrigtsen
` (3 more replies)
2021-02-08 12:36 ` Alan Mackenzie
2021-02-08 21:00 ` Gregory Heytings
2 siblings, 4 replies; 160+ messages in thread
From: Stefan Kangas @ 2021-02-08 7:20 UTC (permalink / raw)
To: rms, Gregory Heytings; +Cc: emacs-devel
Richard Stallman <rms@gnu.org> writes:
> > Option 1. C-z, with a single exception: "C-z C-z" would be bound to
> > "suspend-frame"
>
> I think that these changes for C-z, M-z and C-o would be a big pain in
> the neck.
Indeed.
(But I personally still maintain that `C-z' should just be changed to
`undo'.)
> However, it would be possible to make M-z M-ANYTHING available for
> other bindings and reserve them for whatever we wish. That would not
> conflict with the current meaning of M-z, because meta characters
> can't be in the buffer.
Wouldn't it be strange to first be queried for "Zap up to char: " and
then be expected to type another key to run some command from a
third-party package?
> The binding of M-m is less useful than many other keys.
> Perhaps it could be given to some other use.
Your mileage may vary, but I use `M-m' tens or hundreds of time per day.
Of the global M-bindings, `M-o' seems least useful to me.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 7:20 ` Stefan Kangas
@ 2021-02-08 14:58 ` Lars Ingebrigtsen
2021-02-08 21:00 ` Gregory Heytings
` (2 more replies)
2021-02-08 15:45 ` Thibaut Verron
` (2 subsequent siblings)
3 siblings, 3 replies; 160+ messages in thread
From: Lars Ingebrigtsen @ 2021-02-08 14:58 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Gregory Heytings, rms, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> (But I personally still maintain that `C-z' should just be changed to
> `undo'.)
The problem is that `C-z' is really useful in a terminal, and having the
keystrokes diverge to a great degree between GUI Emacs and terminal
Emacs would be unfortunate.
> Of the global M-bindings, `M-o' seems least useful to me.
Indeed.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 14:58 ` Lars Ingebrigtsen
@ 2021-02-08 21:00 ` Gregory Heytings
2021-02-08 21:33 ` Stefan Monnier
2021-02-08 22:45 ` Stefan Kangas
2 siblings, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-08 21:00 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
>> (But I personally still maintain that `C-z' should just be changed to
>> `undo'.)
>
> The problem is that `C-z' is really useful in a terminal, and having the
> keystrokes diverge to a great degree between GUI Emacs and terminal
> Emacs would be unfortunate.
>
Indeed, C-z is useful in terminals, even though suspend-frame is also
available on C-x C-z. Terminals are the reason why the proposal mentions
that C-z C-z would be (the only) reserved binding in that keymap.
Repeating a key until it produces the expected effect is something
terminal users are habituated to do (for example repeating C-c until the
program aborts).
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 14:58 ` Lars Ingebrigtsen
2021-02-08 21:00 ` Gregory Heytings
@ 2021-02-08 21:33 ` Stefan Monnier
2021-02-09 8:13 ` Lars Ingebrigtsen
2021-02-08 22:45 ` Stefan Kangas
2 siblings, 1 reply; 160+ messages in thread
From: Stefan Monnier @ 2021-02-08 21:33 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Gregory Heytings, emacs-devel, Stefan Kangas, rms
> The problem is that `C-z' is really useful in a terminal, and having the
> keystrokes diverge to a great degree between GUI Emacs and terminal
> Emacs would be unfortunate.
>> Of the global M-bindings, `M-o' seems least useful to me.
> Indeed.
And yet the corresponding feature is *preloaded* :-(
Stefan "whose M-o is unbound because his local Emacs patches
include removing that part of loadup.el"
PS: It took me a bit if digging to figure out why my M-o was unbound.
That's a change I made a very long time ago.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 21:33 ` Stefan Monnier
@ 2021-02-09 8:13 ` Lars Ingebrigtsen
2021-02-09 16:54 ` Sean Whitton
0 siblings, 1 reply; 160+ messages in thread
From: Lars Ingebrigtsen @ 2021-02-09 8:13 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Gregory Heytings, emacs-devel, Stefan Kangas, rms
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> The problem is that `C-z' is really useful in a terminal, and having the
>> keystrokes diverge to a great degree between GUI Emacs and terminal
>> Emacs would be unfortunate.
>>> Of the global M-bindings, `M-o' seems least useful to me.
>> Indeed.
>
> And yet the corresponding feature is *preloaded* :-(
>
> Stefan "whose M-o is unbound because his local Emacs patches
> include removing that part of loadup.el"
>
> PS: It took me a bit if digging to figure out why my M-o was unbound.
> That's a change I made a very long time ago.
We've previously discussed doing time-limited experiments -- perhaps
this is a good test case for that.
That is, I propose that we remove the `M-o' binding on the trunk for one
month, and see how many (if any) complaints we get.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 8:13 ` Lars Ingebrigtsen
@ 2021-02-09 16:54 ` Sean Whitton
2021-02-09 17:13 ` Lars Ingebrigtsen
` (2 more replies)
0 siblings, 3 replies; 160+ messages in thread
From: Sean Whitton @ 2021-02-09 16:54 UTC (permalink / raw)
To: Lars Ingebrigtsen, Stefan Monnier
Cc: Gregory Heytings, Stefan Kangas, rms, emacs-devel
Hello,
On Tue 09 Feb 2021 at 09:13AM +01, Lars Ingebrigtsen wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> The problem is that `C-z' is really useful in a terminal, and having the
>>> keystrokes diverge to a great degree between GUI Emacs and terminal
>>> Emacs would be unfortunate.
>>>> Of the global M-bindings, `M-o' seems least useful to me.
>>> Indeed.
>>
>> And yet the corresponding feature is *preloaded* :-(
>>
>> Stefan "whose M-o is unbound because his local Emacs patches
>> include removing that part of loadup.el"
>>
>> PS: It took me a bit if digging to figure out why my M-o was unbound.
>> That's a change I made a very long time ago.
>
> We've previously discussed doing time-limited experiments -- perhaps
> this is a good test case for that.
>
> That is, I propose that we remove the `M-o' binding on the trunk for one
> month, and see how many (if any) complaints we get.
Aren't the current bindings under M-o intended for that halcyon future
in which we can use Emacs as a word processor, not just a text editor?
Like enriched-mode, but for file formats like .odt, where buffer faces
set with M-o get translated into something in the file format upon save.
I assume that most of the bindings under M-o were made with that sort of
usage of Emacs in mind. It strikes me as a bit sad to unbind M-o as it
would sort of be saying that we no longer think Emacs is ever going to
be much use for editing non-plain text.
--
Sean Whitton
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 16:54 ` Sean Whitton
@ 2021-02-09 17:13 ` Lars Ingebrigtsen
2021-02-09 17:43 ` Eli Zaretskii
2021-02-09 18:37 ` Stefan Monnier
2 siblings, 0 replies; 160+ messages in thread
From: Lars Ingebrigtsen @ 2021-02-09 17:13 UTC (permalink / raw)
To: Sean Whitton
Cc: Gregory Heytings, Stefan Kangas, Stefan Monnier, rms, emacs-devel
Sean Whitton <spwhitton@spwhitton.name> writes:
> Aren't the current bindings under M-o intended for that halcyon future
> in which we can use Emacs as a word processor, not just a text editor?
> Like enriched-mode, but for file formats like .odt, where buffer faces
> set with M-o get translated into something in the file format upon save.
That's my guess, but they make little sense as global bindings.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 16:54 ` Sean Whitton
2021-02-09 17:13 ` Lars Ingebrigtsen
@ 2021-02-09 17:43 ` Eli Zaretskii
2021-02-09 21:21 ` Sean Whitton
2021-02-09 18:37 ` Stefan Monnier
2 siblings, 1 reply; 160+ messages in thread
From: Eli Zaretskii @ 2021-02-09 17:43 UTC (permalink / raw)
To: Sean Whitton; +Cc: rms, emacs-devel, gregory, monnier, larsi, stefankangas
> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Tue, 09 Feb 2021 09:54:59 -0700
> Cc: Gregory Heytings <gregory@heytings.org>,
> Stefan Kangas <stefankangas@gmail.com>, rms@gnu.org, emacs-devel@gnu.org
>
> Aren't the current bindings under M-o intended for that halcyon future
> in which we can use Emacs as a word processor, not just a text editor?
> Like enriched-mode, but for file formats like .odt, where buffer faces
> set with M-o get translated into something in the file format upon save.
>
> I assume that most of the bindings under M-o were made with that sort of
> usage of Emacs in mind. It strikes me as a bit sad to unbind M-o as it
> would sort of be saying that we no longer think Emacs is ever going to
> be much use for editing non-plain text.
We could make these bindings local to the modes where they are
relevant, for example Text mode and its descendants. There's no need
for a global binding, at least not necessarily.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 17:43 ` Eli Zaretskii
@ 2021-02-09 21:21 ` Sean Whitton
0 siblings, 0 replies; 160+ messages in thread
From: Sean Whitton @ 2021-02-09 21:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rms, emacs-devel, gregory, stefankangas, larsi, monnier
Hello,
On Tue 09 Feb 2021 at 07:43PM +02, Eli Zaretskii wrote:
>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Date: Tue, 09 Feb 2021 09:54:59 -0700
>> Cc: Gregory Heytings <gregory@heytings.org>,
>> Stefan Kangas <stefankangas@gmail.com>, rms@gnu.org, emacs-devel@gnu.org
>>
>> Aren't the current bindings under M-o intended for that halcyon future
>> in which we can use Emacs as a word processor, not just a text editor?
>> Like enriched-mode, but for file formats like .odt, where buffer faces
>> set with M-o get translated into something in the file format upon save.
>>
>> I assume that most of the bindings under M-o were made with that sort of
>> usage of Emacs in mind. It strikes me as a bit sad to unbind M-o as it
>> would sort of be saying that we no longer think Emacs is ever going to
>> be much use for editing non-plain text.
>
> We could make these bindings local to the modes where they are
> relevant, for example Text mode and its descendants. There's no need
> for a global binding, at least not necessarily.
I agree that it would be good to find a non-global way to do this.
Perhaps we could set up a major mode to be inherited by modes like
enriched-mode, which sets up a binding which is at least as convenient
to use as M-o is right now?
That way we can ensure that the bindings to set faces are consistent
between major modes, which is what we would be at risk of losing if we
drop the global binding.
For the sake of ease of use I'd suggest replacing M-o b with C-c C-c b.
Does this sound sensible? It would be a shame if we ended up with each
possible WYSIWYG mode defining its own face-setting bindings.
Also, new non-WYSIWYG modes could re-use the same bindings to, e.g.,
insert asterisks around text meant to be bold.
--
Sean Whitton
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 16:54 ` Sean Whitton
2021-02-09 17:13 ` Lars Ingebrigtsen
2021-02-09 17:43 ` Eli Zaretskii
@ 2021-02-09 18:37 ` Stefan Monnier
2 siblings, 0 replies; 160+ messages in thread
From: Stefan Monnier @ 2021-02-09 18:37 UTC (permalink / raw)
To: Sean Whitton
Cc: Lars Ingebrigtsen, Stefan Kangas, Gregory Heytings, rms,
emacs-devel
> I assume that most of the bindings under M-o were made with that sort of
> usage of Emacs in mind.
That's my impression as well.
> It strikes me as a bit sad to unbind M-o as it would sort of be saying
> that we no longer think Emacs is ever going to be much use for editing
> non-plain text.
No, I think it's just normal: if/when you want to use Emacs as a WYSISYG
editor, it'll have to be in a dedicated (set of) modes. Those can then
provide bindings like the ones we currently have under M-o. But having
those bindings in the global map just doesn't make much sense.
Stefan
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 14:58 ` Lars Ingebrigtsen
2021-02-08 21:00 ` Gregory Heytings
2021-02-08 21:33 ` Stefan Monnier
@ 2021-02-08 22:45 ` Stefan Kangas
2 siblings, 0 replies; 160+ messages in thread
From: Stefan Kangas @ 2021-02-08 22:45 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Gregory Heytings, rms, emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> (But I personally still maintain that `C-z' should just be changed to
>> `undo'.)
>
> The problem is that `C-z' is really useful in a terminal, and having the
> keystrokes diverge to a great degree between GUI Emacs and terminal
> Emacs would be unfortunate.
Yes, those are valid concerns.
OTOH, we also provide `C-x C-z'. My personal preference would be for
Emacs to be weird in having suspend [in terminal] on a non-conventional
key, rather than undo [in terminal and GUI]. But that's me.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 7:20 ` Stefan Kangas
2021-02-08 14:58 ` Lars Ingebrigtsen
@ 2021-02-08 15:45 ` Thibaut Verron
2021-02-08 23:01 ` Stefan Kangas
2021-02-08 21:00 ` Gregory Heytings
2021-02-09 6:03 ` Richard Stallman
3 siblings, 1 reply; 160+ messages in thread
From: Thibaut Verron @ 2021-02-08 15:45 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Gregory Heytings, rms, emacs-devel
>> The binding of M-m is less useful than many other keys.
>> Perhaps it could be given to some other use.
>
> Your mileage may vary, but I use `M-m' tens or hundreds of time per day.
I'm also using it a lot, so much actually that I rebound it to C-a
(with a test so that C-a C-a does beginning-of-line). So I would not
miss M-m at all.
Do you also use plain C-a (in scenarios where it disagrees with M-m)
hundreds of times per day?
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 15:45 ` Thibaut Verron
@ 2021-02-08 23:01 ` Stefan Kangas
2021-02-09 9:13 ` Simen Heggestøyl
2021-02-09 9:30 ` Juri Linkov
0 siblings, 2 replies; 160+ messages in thread
From: Stefan Kangas @ 2021-02-08 23:01 UTC (permalink / raw)
To: thibaut.verron; +Cc: Gregory Heytings, rms, emacs-devel
Thibaut Verron <thibaut.verron@gmail.com> writes:
>> Your mileage may vary, but I use `M-m' tens or hundreds of time per day.
>
> I'm also using it a lot, so much actually that I rebound it to C-a
> (with a test so that C-a C-a does beginning-of-line).
I never considered making such a binding globally. It's a good idea.
(I don't want to fan the flames, but this makes me wonder why `C-a' does
not already default to this behavior...)
> Do you also use plain C-a (in scenarios where it disagrees with M-m)
> hundreds of times per day?
Yes, I use `C-a' more frequently than `M-m'.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 23:01 ` Stefan Kangas
@ 2021-02-09 9:13 ` Simen Heggestøyl
2021-02-09 9:30 ` Juri Linkov
1 sibling, 0 replies; 160+ messages in thread
From: Simen Heggestøyl @ 2021-02-09 9:13 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Gregory Heytings, rms, thibaut.verron, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Thibaut Verron <thibaut.verron@gmail.com> writes:
>
>>> Your mileage may vary, but I use `M-m' tens or hundreds of time per day.
>>
>> I'm also using it a lot, so much actually that I rebound it to C-a
>> (with a test so that C-a C-a does beginning-of-line).
>
> I never considered making such a binding globally. It's a good idea.
>
> (I don't want to fan the flames, but this makes me wonder why `C-a' does
> not already default to this behavior...)
I also like this behavior. I made the same binding as Thibaut many years
ago, and have never missed the old behavior.
-- Simen
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 23:01 ` Stefan Kangas
2021-02-09 9:13 ` Simen Heggestøyl
@ 2021-02-09 9:30 ` Juri Linkov
2021-02-09 13:01 ` Gregory Heytings
1 sibling, 1 reply; 160+ messages in thread
From: Juri Linkov @ 2021-02-09 9:30 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Gregory Heytings, rms, thibaut.verron, emacs-devel
>>> Your mileage may vary, but I use `M-m' tens or hundreds of time per day.
>>
>> I'm also using it a lot, so much actually that I rebound it to C-a
>> (with a test so that C-a C-a does beginning-of-line).
>
> I never considered making such a binding globally. It's a good idea.
>
> (I don't want to fan the flames, but this makes me wonder why `C-a' does
> not already default to this behavior...)
For a long time I have been using such logic bound to `C-a':
(if (bolp)
(beginning-of-line-text arg) ;; or (back-to-indentation)
(if (fboundp 'move-beginning-of-line)
(move-beginning-of-line arg)
(beginning-of-line arg)))
But I don't remember the difference between beginning-of-line-text and
back-to-indentation and which one is better, neither the difference
between beginning-of-line and move-beginning-of-line.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 9:30 ` Juri Linkov
@ 2021-02-09 13:01 ` Gregory Heytings
0 siblings, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-09 13:01 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
>
> For a long time I have been using such logic bound to `C-a':
>
> (if (bolp)
> (beginning-of-line-text arg) ;; or (back-to-indentation)
> (if (fboundp 'move-beginning-of-line)
> (move-beginning-of-line arg)
> (beginning-of-line arg)))
>
> But I don't remember the difference between beginning-of-line-text and
> back-to-indentation and which one is better, neither the difference
> between beginning-of-line and move-beginning-of-line.
>
The main difference between back-to-indentation and beginning-of-line-text
is that back-to-indentation ignores the fill-prefix. With a buffer with
the following two lines:
1234
>>>> 5678
with point on "4:
- move-beginning-of-line moves point to the beginning of the line
- back-to-indentation moves point to "1"
- beginning-of-line-text moves point to "1"
with point on "8":
- move-beginning-of-line moves point to the beginning of the line
- back-to-indentation moves point to the beginning of the line
- beginning-of-line-text moves point to "5"
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 7:20 ` Stefan Kangas
2021-02-08 14:58 ` Lars Ingebrigtsen
2021-02-08 15:45 ` Thibaut Verron
@ 2021-02-08 21:00 ` Gregory Heytings
2021-02-09 6:03 ` Richard Stallman
3 siblings, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-08 21:00 UTC (permalink / raw)
To: Stefan Kangas; +Cc: emacs-devel
>
> (But I personally still maintain that `C-z' should just be changed to
> `undo'.)
>
IMO that would be the worst possible binding for C-z. "Undo" is already
bound to no less than three different keys. Binding it to yet another key
just to make Emacs feel closer to other editors, when all other bindings
are so different from other editors anyway, would (IMO again) be a serious
mistake.
>
> Of the global M-bindings, `M-o' seems least useful to me.
>
Leaving just one meta key (in this case M-o) for third-party packages
would IMO not be enough to motivate their developers to put their default
bindings there; third-party packages should not be considered as
second-class citizens. It must either be a control key alone, or a
control key and its corresponding meta key.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 7:20 ` Stefan Kangas
` (2 preceding siblings ...)
2021-02-08 21:00 ` Gregory Heytings
@ 2021-02-09 6:03 ` Richard Stallman
3 siblings, 0 replies; 160+ messages in thread
From: Richard Stallman @ 2021-02-09 6:03 UTC (permalink / raw)
To: Stefan Kangas; +Cc: gregory, emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > However, it would be possible to make M-z M-ANYTHING available for
> > other bindings and reserve them for whatever we wish. That would not
> > conflict with the current meaning of M-z, because meta characters
> > can't be in the buffer.
> Wouldn't it be strange to first be queried for "Zap up to char: " and
> then be expected to type another key to run some command from a
> third-party package?
Yes, it would be -- but we can deal with that.
The promp could say "Next Meta-character, or zap up to char:".
It could wait a second before prompting, so that experienced users
normally would not wait so long before typing the next key.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 3:46 ` Richard Stallman
2021-02-08 7:20 ` Stefan Kangas
@ 2021-02-08 12:36 ` Alan Mackenzie
2021-02-08 21:00 ` Gregory Heytings
2 siblings, 0 replies; 160+ messages in thread
From: Alan Mackenzie @ 2021-02-08 12:36 UTC (permalink / raw)
To: Richard Stallman; +Cc: Gregory Heytings, emacs-devel
Hello, Richard.
On Sun, Feb 07, 2021 at 22:46:37 -0500, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > Option 1. C-z, with a single exception: "C-z C-z" would be bound to
> > "suspend-frame"
> I think that these changes for C-z, M-z and C-o would be a big pain in
> the neck.
> However, it would be possible to make M-z M-ANYTHING available for
> other bindings and reserve them for whatever we wish. That would not
> conflict with the current meaning of M-z, because meta characters
> can't be in the buffer.
> The binding of M-m is less useful than many other keys. Perhaps it
> could be given to some other use.
Please not. I use M-m frequently. If that binding were to be removed,
there would be no good way of doing what it does. C-a M-f M-b is not
good. I think the existence of bindings like C-o and M-m is one of the
differences between Emacs and lesser editors that makes Emacs so good.
I don't use C-z or M-z myself, but that's no reason for me to advocate
reassigning those keys to something else.
> --
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 3:46 ` Richard Stallman
2021-02-08 7:20 ` Stefan Kangas
2021-02-08 12:36 ` Alan Mackenzie
@ 2021-02-08 21:00 ` Gregory Heytings
2 siblings, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-08 21:00 UTC (permalink / raw)
To: Richard Stallman; +Cc: emacs-devel
>
> I think that these changes for C-z, M-z and C-o would be a big pain in
> the neck.
>
Could you perhaps elaborate a bit what you mean by this? For example, why
would typing "C-z C-z" instead of "C-z" to suspend, something you
presumably don't do once a minute, be "a big pain in the neck"?
There is a problem in need for a solution. If nobody agrees to make small
concessions it will forever remain a problem, with on the one hand
repeated conflicts and animosity between Emacs and package developers, and
on the other hand unnecessary complexity to install packages for Emacs
users.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-07 22:05 Gregory Heytings
` (2 preceding siblings ...)
2021-02-08 3:46 ` Richard Stallman
@ 2021-02-08 4:52 ` Robin Tarsiger
2021-02-08 8:41 ` Thibaut Verron
` (2 more replies)
2021-02-08 12:42 ` Augusto Stoffel
` (4 subsequent siblings)
8 siblings, 3 replies; 160+ messages in thread
From: Robin Tarsiger @ 2021-02-08 4:52 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 4:52 ` Robin Tarsiger
@ 2021-02-08 8:41 ` Thibaut Verron
2021-02-08 17:07 ` Robin Tarsiger
2021-02-11 12:59 ` Arthur Miller
2021-02-08 21:00 ` Gregory Heytings
2021-02-08 23:14 ` Stefan Monnier
2 siblings, 2 replies; 160+ messages in thread
From: Thibaut Verron @ 2021-02-08 8:41 UTC (permalink / raw)
To: Robin Tarsiger; +Cc: emacs-devel
2021-02-08 5:52 UTC+01:00, Robin Tarsiger <rtt@dasyatidae.com>:
> 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.
https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html
Those keys are explicitly left for the user to define.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 8:41 ` Thibaut Verron
@ 2021-02-08 17:07 ` Robin Tarsiger
2021-02-11 12:59 ` Arthur Miller
1 sibling, 0 replies; 160+ messages in thread
From: Robin Tarsiger @ 2021-02-08 17:07 UTC (permalink / raw)
To: emacs-devel
Thibaut Verron wrote:
[re f5--f8]
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html
>
> Those keys are explicitly left for the user to define.
D'oh, I thought I checked that. My mistake; never mind.
-RTT "if sleepy, wait until morning before hitting Send"
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 8:41 ` Thibaut Verron
2021-02-08 17:07 ` Robin Tarsiger
@ 2021-02-11 12:59 ` Arthur Miller
1 sibling, 0 replies; 160+ messages in thread
From: Arthur Miller @ 2021-02-11 12:59 UTC (permalink / raw)
To: Thibaut Verron; +Cc: Robin Tarsiger, emacs-devel
Thibaut Verron <thibaut.verron@gmail.com> writes:
> 2021-02-08 5:52 UTC+01:00, Robin Tarsiger <rtt@dasyatidae.com>:
>> 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.
>
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html
>
> Those keys are explicitly left for the user to define.
What I see is missing here, is the most important option: to hire a
secretary to Mr. Eli so he can actually get some work done amongst this
flood of emails going on for days now on this über-important topic of
which key to use or not use ... :-)
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 4:52 ` Robin Tarsiger
2021-02-08 8:41 ` Thibaut Verron
@ 2021-02-08 21:00 ` Gregory Heytings
2021-02-09 7:42 ` Yuri Khan
2021-02-08 23:14 ` Stefan Monnier
2 siblings, 1 reply; 160+ messages in thread
From: Gregory Heytings @ 2021-02-08 21:00 UTC (permalink / raw)
To: Robin Tarsiger; +Cc: emacs-devel
>
> 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.
>
That would be the case, by design. One or two keymaps would be created,
which you could assign to any other key. For example you can move all C-x
bindings to F7 with (progn (define-key global-map (kbd "<f7>") ctl-x-map)
(define-key global-map (kbd "C-x") nil)).
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 21:00 ` Gregory Heytings
@ 2021-02-09 7:42 ` Yuri Khan
2021-02-09 8:23 ` Gregory Heytings
0 siblings, 1 reply; 160+ messages in thread
From: Yuri Khan @ 2021-02-09 7:42 UTC (permalink / raw)
To: Gregory Heytings; +Cc: Robin Tarsiger, Emacs developers
On Tue, 9 Feb 2021 at 07:37, Gregory Heytings <gregory@heytings.org> wrote:
> For example you can move all C-x
> bindings to F7 with (progn (define-key global-map (kbd "<f7>") ctl-x-map)
> (define-key global-map (kbd "C-x") nil)).
Does it work that easily though? I might like to do that to C-x and
C-c so that I could bind those to Cut and Copy[^1]. But no:
$ emacs -Q
(define-key global-map (kbd "<f7>") ctl-x-map) ;; C-x C-e
(define-key global-map (kbd "C-x") #'kill-region) ;; f7 C-e
(+ 2 2) ;; C-x C-e ⇒ no effect; f7 C-e ⇒ 4
C-r buffer RET C-S-right C-x
Expected: the word is killed.
Observed: I get a “C-x-” prompt in the minibuffer, indicating C-x is
still acting as a prefix key. Indeed, pressing C-h reveals a number of
C-x 8 … bindings in key translations, and a bunch of C-x @ … bindings
in function key map translations.
M-x hl-lock-mode RET
C-s define-key M-C-B C-x w .
Expected: “define-key” is killed and replaced with “w.”.
Observed: ‘highlight-symbol-at-point’ picks up “define-key” and
highlights its all occurrences.
[^1]: Yes, I know of and use cua-mode. No, it’s not satisfying.
Because with all this pandemic work-from-home, my Emacs is over there
at my office, and it’s displaying its frames on my X server here at my
home[^2], and network lag interferes with the timeout-based heuristic
that causes cua-mode to cut where I intended to do a prefix C-x, or
vice versa, to switch buffers when I intended to cut and then move
point left or right.
[^2]: Yes, I know about Tramp, but have not made it part of my
workflow, partially because I’m unsure if eglot will work over tramp.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 7:42 ` Yuri Khan
@ 2021-02-09 8:23 ` Gregory Heytings
0 siblings, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-09 8:23 UTC (permalink / raw)
To: Yuri Khan; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
>> For example you can move all C-x bindings to F7 with (progn (define-key
>> global-map (kbd "<f7>") ctl-x-map) (define-key global-map (kbd "C-x")
>> nil)).
>
> Does it work that easily though?
>
No it doesn't, it was just a short proof of concept, which works mostly.
>
> Observed: I get a “C-x-” prompt in the minibuffer, indicating C-x is
> still acting as a prefix key. Indeed, pressing C-h reveals a number of
> C-x 8 … bindings in key translations, and a bunch of C-x @ … bindings in
> function key map translations.
>
Yes, as Andreas Schwab explained a few days ago in another thread, this is
because C-x is a prefix key on the key-translation-map.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 4:52 ` Robin Tarsiger
2021-02-08 8:41 ` Thibaut Verron
2021-02-08 21:00 ` Gregory Heytings
@ 2021-02-08 23:14 ` Stefan Monnier
2021-02-09 8:23 ` Gregory Heytings
2 siblings, 1 reply; 160+ messages in thread
From: Stefan Monnier @ 2021-02-08 23:14 UTC (permalink / raw)
To: Robin Tarsiger; +Cc: emacs-devel
> 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.
Yes, focusing on the keymap first and presuming that its actual binding
may change seems important. Tho in practice, when a keymap is bound
changes which bindings inside the map are convenient to type:
E.g. `C-z C-z` is much easier to type than `M-o C-z`.
Stefan
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 23:14 ` Stefan Monnier
@ 2021-02-09 8:23 ` Gregory Heytings
0 siblings, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-09 8:23 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
>> 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.
>
> Yes, focusing on the keymap first and presuming that its actual binding
> may change seems important. Tho in practice, when a keymap is bound
> changes which bindings inside the map are convenient to type: E.g. `C-z
> C-z` is much easier to type than `M-o C-z`.
>
And in practice, too, there is no chance third-party library developers
would agree to use that keymap if it is not bound by default to a sensible
key. It must be an appealing solution.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-07 22:05 Gregory Heytings
` (3 preceding siblings ...)
2021-02-08 4:52 ` Robin Tarsiger
@ 2021-02-08 12:42 ` Augusto Stoffel
2021-02-08 21:00 ` Gregory Heytings
2021-02-08 14:54 ` Dmitry Gutov
` (3 subsequent siblings)
8 siblings, 1 reply; 160+ messages in thread
From: Augusto Stoffel @ 2021-02-08 12:42 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
Surely lots of people rebind some non-prefix keys of dubious usefulness
like ‘C-z’ and ‘M-o’ (I bet I'm not alone in using those for
‘switch-to-buffer’ and ‘other-window’ respectively).
Now, as long as there is a _keymap_ for third-party packages, which
users can move wherever they see fit, I wouldn't care about the default
bindings. But it's important not to leave room for the interpretation
that the third-party keymap will always be bound to its default key.
Best,
Augusto
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 12:42 ` Augusto Stoffel
@ 2021-02-08 21:00 ` Gregory Heytings
0 siblings, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-08 21:00 UTC (permalink / raw)
To: Augusto Stoffel; +Cc: emacs-devel
>
> Now, as long as there is a _keymap_ for third-party packages, which
> users can move wherever they see fit, I wouldn't care about the default
> bindings. But it's important not to leave room for the interpretation
> that the third-party keymap will always be bound to its default key.
>
Yes, that would be the case, by design. One or two keymaps would be
created, which anyone could move to another key if need be. The point of
the proposal is to discuss the default bindings of that keymap/these
keymaps. Without sensible default bindings, there's no point in creating
such keymaps.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-07 22:05 Gregory Heytings
` (4 preceding siblings ...)
2021-02-08 12:42 ` Augusto Stoffel
@ 2021-02-08 14:54 ` Dmitry Gutov
2021-02-08 21:00 ` Gregory Heytings
2021-02-08 17:59 ` Sean Whitton
` (2 subsequent siblings)
8 siblings, 1 reply; 160+ messages in thread
From: Dmitry Gutov @ 2021-02-08 14:54 UTC (permalink / raw)
To: Gregory Heytings, emacs-devel
On 08.02.2021 00:05, Gregory Heytings wrote:
>
> =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"
This won't fly because a lot of us bind 'C-z' to 'undo' (or a similar
command), and special-casing 'C-z C-z' would break that usage (calling
'undo' several times in a row is common).
Finally, like Stefan K said in another thread, if we even end up
changing the 'C-z' binding, let's finally make it compatible with most
other editors out there, which is putting 'undo' on it. Or 'undo-only'.
And as a maintainer of multiple packages, I have lost track of how many
times I switch to 'emacs -Q' to reproduce some bug report, and then end
up suspending the frame by accident.
> 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"
I'd prefer to keep 'C-o' as-is, but admittedly it's a less important
binding.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 14:54 ` Dmitry Gutov
@ 2021-02-08 21:00 ` Gregory Heytings
0 siblings, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-08 21:00 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
>
> This won't fly because a lot of us bind 'C-z' to 'undo' (or a similar
> command), and special-casing 'C-z C-z' would break that usage (calling
> 'undo' several times in a row is common).
>
You would (of course) still be free to do this, what is proposed is only a
default keybinding for a new keymap reserved for third-party packages.
As I said to Stefan K, undo is already on three keys, using (I'm tempted
to say "wasting") yet another key for this by default would be most
regrettable.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-07 22:05 Gregory Heytings
` (5 preceding siblings ...)
2021-02-08 14:54 ` Dmitry Gutov
@ 2021-02-08 17:59 ` Sean Whitton
2021-02-08 22:40 ` Eric Abrahamsen
2021-02-08 20:32 ` Ulrich Mueller
[not found] ` <8735y56naf.fsf@posteo.net>
8 siblings, 1 reply; 160+ messages in thread
From: Sean Whitton @ 2021-02-08 17:59 UTC (permalink / raw)
To: Gregory Heytings, emacs-devel
Hello Gregory,
On Sun 07 Feb 2021 at 10:05PM GMT, Gregory Heytings wrote:
> 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"
C-z seems like the obvious choice out of these -- it's a duplicate
binding, there was a lot of support for repurposing it in that recent
thread, and those who were a bit reticent about repurposing were okay
with the idea of C-z C-z suspending the frame with something in the
message area after a single C-z.
Thanks for the proposal.
--
Sean Whitton
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 17:59 ` Sean Whitton
@ 2021-02-08 22:40 ` Eric Abrahamsen
2021-02-09 16:45 ` Sean Whitton
0 siblings, 1 reply; 160+ messages in thread
From: Eric Abrahamsen @ 2021-02-08 22:40 UTC (permalink / raw)
To: emacs-devel
Sean Whitton <spwhitton@spwhitton.name> writes:
> Hello Gregory,
>
> On Sun 07 Feb 2021 at 10:05PM GMT, Gregory Heytings wrote:
>
>> 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"
>
> C-z seems like the obvious choice out of these -- it's a duplicate
> binding, there was a lot of support for repurposing it in that recent
> thread, and those who were a bit reticent about repurposing were okay
> with the idea of C-z C-z suspending the frame with something in the
> message area after a single C-z.
If C-x C-z is already `suspend-frame', do we really need C-z C-z, too?
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 22:40 ` Eric Abrahamsen
@ 2021-02-09 16:45 ` Sean Whitton
2021-02-10 5:28 ` Richard Stallman
2021-02-12 9:40 ` Jean Louis
0 siblings, 2 replies; 160+ messages in thread
From: Sean Whitton @ 2021-02-09 16:45 UTC (permalink / raw)
To: Eric Abrahamsen, emacs-devel
Hello,
On Mon 08 Feb 2021 at 02:40PM -08, Eric Abrahamsen wrote:
> If C-x C-z is already `suspend-frame', do we really need C-z C-z, too?
As has been mentioned, the thought is that a terminal user who doesn't
know much about Emacs will probably just hit it a second time if it
doesn't do what they expect.
--
Sean Whitton
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 16:45 ` Sean Whitton
@ 2021-02-10 5:28 ` Richard Stallman
2021-02-10 9:29 ` Thibaut Verron
` (2 more replies)
2021-02-12 9:40 ` Jean Louis
1 sibling, 3 replies; 160+ messages in thread
From: Richard Stallman @ 2021-02-10 5:28 UTC (permalink / raw)
To: Sean Whitton; +Cc: eric, emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Suppose we reserve one key for third-party packages. Let's refer to
that key as C-α, to avoid specifying which key is chosen.
Various packages will set up their own bindings for it. If you load
more than one such package, which package's bindings will you get?
How do you get the ones you want?
Here's an idea.
Have one command you can use to specify which package's bindings C-α
will run. It could be C-α C-α; then individual packages will not give
their own bindings for C-α C-α.
So you can type C-α C-α Foopkg RET, then C-α gives you the Foopkg bindings.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 5:28 ` Richard Stallman
@ 2021-02-10 9:29 ` Thibaut Verron
2021-02-11 13:37 ` Richard Stallman
2021-02-10 10:42 ` Alfred M. Szmidt
2021-02-10 11:07 ` Gregory Heytings
2 siblings, 1 reply; 160+ messages in thread
From: Thibaut Verron @ 2021-02-10 9:29 UTC (permalink / raw)
To: rms; +Cc: eric, emacs-devel, Sean Whitton
2021-02-10 6:28 UTC+01:00, Richard Stallman <rms@gnu.org>:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Suppose we reserve one key for third-party packages. Let's refer to
> that key as C-α, to avoid specifying which key is chosen.
>
> Various packages will set up their own bindings for it. If you load
> more than one such package, which package's bindings will you get?
> How do you get the ones you want?
>
> Here's an idea.
>
> Have one command you can use to specify which package's bindings C-α
> will run. It could be C-α C-α; then individual packages will not give
> their own bindings for C-α C-α.
>
> So you can type C-α C-α Foopkg RET, then C-α gives you the Foopkg bindings.
That seems like an extremely valuable binding to sacrifice for a
command which will most likely be only run once.
But maybe we could agree on a specific key, identical on all keymaps,
for that purpose. That would be similar to how C-\alpha ? is currently
reserved for describe-keymap.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 9:29 ` Thibaut Verron
@ 2021-02-11 13:37 ` Richard Stallman
2021-02-11 13:52 ` Thibaut Verron
0 siblings, 1 reply; 160+ messages in thread
From: Richard Stallman @ 2021-02-11 13:37 UTC (permalink / raw)
To: thibaut.verron; +Cc: eric, emacs-devel, spwhitton
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > So you can type C-α C-α Foopkg RET, then C-α gives you the Foopkg bindings.
> That seems like an extremely valuable binding to sacrifice for a
> command which will most likely be only run once.
Why do you think C-α C-α would be so valuable? I don't get it.
(This is supposing we have made C-α a prefix for use by external packages.)
> But maybe we could agree on a specific key, identical on all keymaps,
> for that purpose. That would be similar to how C-\alpha ? is currently
> reserved for describe-keymap.
How is that different from what I said?
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-11 13:37 ` Richard Stallman
@ 2021-02-11 13:52 ` Thibaut Verron
0 siblings, 0 replies; 160+ messages in thread
From: Thibaut Verron @ 2021-02-11 13:52 UTC (permalink / raw)
To: rms; +Cc: eric, emacs-devel, spwhitton
2021-02-11 14:37 UTC+01:00, Richard Stallman <rms@gnu.org>:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > > So you can type C-α C-α Foopkg RET, then C-α gives you the Foopkg
> bindings.
>
> > That seems like an extremely valuable binding to sacrifice for a
> > command which will most likely be only run once.
>
> Why do you think C-α C-α would be so valuable? I don't get it.
Because it is easier to press the same key twice than another key.
See for example how many people support freeing C-z while keeping its
current behavior on C-z C-z.
> (This is supposing we have made C-α a prefix for use by external packages.)
I don't understand the suggestion anymore then. What would the
C-\alpha keymap look like? One package on C-\alpha a, one on C-\alpha
b, etc? Or just one on C-\alpha?
> > But maybe we could agree on a specific key, identical on all keymaps,
> > for that purpose. That would be similar to how C-\alpha ? is currently
> > reserved for describe-keymap.
>
> How is that different from what I said?
The choice of a different second key than the prefix C-\alpha. Besides
keeping the valuable repeated binding free, it also allows to have the
same key across keymaps.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 5:28 ` Richard Stallman
2021-02-10 9:29 ` Thibaut Verron
@ 2021-02-10 10:42 ` Alfred M. Szmidt
2021-02-10 11:35 ` Thibaut Verron
2021-02-11 13:37 ` Richard Stallman
2021-02-10 11:07 ` Gregory Heytings
2 siblings, 2 replies; 160+ messages in thread
From: Alfred M. Szmidt @ 2021-02-10 10:42 UTC (permalink / raw)
To: rms; +Cc: eric, emacs-devel, spwhitton
Since Magit is a VC like mode, wouldn't it make more sense to put it
under C-x v? E.g., why cannot Magit rebind C-x v l -- which I guess
is similar to magit-status or possibly C-x v d.
From a users perspective, making it seemingly a part of VC-mode makes
more sense than trying to make it a special citizen that needs to take
C-x g (or whatever) since it would make it hard to use MaGit,
MaFossil, MaSubersion (last two are fictious) .... together. Magit
only makes sense for a git repository, you might want to have C-x v l
(or some other status command) invoke the different "viewer". If
Magit (e.g.) has other global bindings that make sense for version
control, those also make more sense to put under C-x v.
We already sorta do it with M-., M-, etc where a package can set up
the right variables to get the right tag jumping functions invoked.
Similarly, for e.g. Bookmark+ (Drew, not suggesting that you rebind
anything :), wouldn't it make better usage if those keybindings are
put under C-x r like the rest of the bookmark bindings?
I am just thinking as a user, where I could expect things to be; and
realise that this might not follow the current Emacs keybinding
policies. It is strange to reserve a third party key, globally, for
usage where you cannot ever really know what that key does --
shouldn't such a key be up to the user?
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 10:42 ` Alfred M. Szmidt
@ 2021-02-10 11:35 ` Thibaut Verron
2021-02-10 12:59 ` Alfred M. Szmidt
2021-02-11 13:37 ` Richard Stallman
1 sibling, 1 reply; 160+ messages in thread
From: Thibaut Verron @ 2021-02-10 11:35 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: eric, spwhitton, rms, emacs-devel
2021-02-10 11:42 UTC+01:00, Alfred M. Szmidt <ams@gnu.org>:
> Since Magit is a VC like mode, wouldn't it make more sense to put it
> under C-x v? E.g., why cannot Magit rebind C-x v l -- which I guess
> is similar to magit-status or possibly C-x v d.
>
> From a users perspective, making it seemingly a part of VC-mode makes
> more sense than trying to make it a special citizen that needs to take
> C-x g (or whatever) since it would make it hard to use MaGit,
> MaFossil, MaSubersion (last two are fictious) .... together. Magit
> only makes sense for a git repository, you might want to have C-x v l
> (or some other status command) invoke the different "viewer". If
> Magit (e.g.) has other global bindings that make sense for version
> control, those also make more sense to put under C-x v.
The problem is that magit-status is both a "visualization" mode,
similar to C-x v d or C-x v l, and a "dispatcher" mode, similar to C-x
v.
An example of usage includes, for example, C-x g c - a c <enter a
commit message> C-c C-c.
This is the equivalent of git commit -a <enter commit message> C-x C-s
C-x k RET.
I can't see a 'vc-commit' function in C-x v, but if there was one, C-x
g c would essentially replace it.
Similarly C-x g P is a vc-push, C-x g F is a (hypothetical) vc-fetch,
C-x g d is a vc-diff, etc.
As such, magit would be better seen as a replacement of the whole vc
keymap than as a part of it. And I don't know if anybody uses both
magit and vc-mode for git version control.
(I occasionally use vc-merge-conflict, but this is not on C-x v.)
But I'm not claiming that rebinding C-x v to magit whenever we are in
a git repository would be a good idea. :)
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 11:35 ` Thibaut Verron
@ 2021-02-10 12:59 ` Alfred M. Szmidt
0 siblings, 0 replies; 160+ messages in thread
From: Alfred M. Szmidt @ 2021-02-10 12:59 UTC (permalink / raw)
To: thibaut.verron; +Cc: eric, spwhitton, rms, emacs-devel
An example of usage includes, for example, C-x g c - a c <enter a
commit message> C-c C-c.
This is the equivalent of git commit -a <enter commit message> C-x C-s
C-x k RET.
I can't see a 'vc-commit' function in C-x v, but if there was one, C-x
g c would essentially replace it.
vc-next-action (C-x v v) does exactly that.
Similarly C-x g P is a vc-push, C-x g F is a (hypothetical) vc-fetch,
C-x g d is a vc-diff, etc.
C-x v P vc-push
C-x v + vc-update
C-x v = vc-diff
So in the case of Magit, why should there be two bindings for two
version control modes?
But I'm not claiming that rebinding C-x v to magit whenever we are in
a git repository would be a good idea. :)
Maybe it is? If magit is supposed to be a git-only replacement for
vc-mode, maybe that is exactly what it should do. Or better yet,
integrate better with vc-mode proper.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 10:42 ` Alfred M. Szmidt
2021-02-10 11:35 ` Thibaut Verron
@ 2021-02-11 13:37 ` Richard Stallman
2021-02-11 14:38 ` Stefan Kangas
1 sibling, 1 reply; 160+ messages in thread
From: Richard Stallman @ 2021-02-11 13:37 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: eric, spwhitton, emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Since Magit is a VC like mode, wouldn't it make more sense to put it
> under C-x v? E.g., why cannot Magit rebind C-x v l -- which I guess
> is similar to magit-status or possibly C-x v d.
I think you are suggesting that the key C-x v could be used both by VC
and by Magit. That could make sense, if users generally use one or
the other. There could be a command to switch C-x v to the VC
bindings and a command to switch it to the Magit bindings.
Or perhaps it can be selected by whether the current buffer uses
a vcs other than git. The options of the global switch could be
* Always use VC
* Always use Magit
* Use VC when the current buffer is stored in a vcs other than git,
otherwise use Magit.
The third one might need some new low-level keymap facility.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-11 13:37 ` Richard Stallman
@ 2021-02-11 14:38 ` Stefan Kangas
2021-02-11 15:13 ` Robert Pluim
0 siblings, 1 reply; 160+ messages in thread
From: Stefan Kangas @ 2021-02-11 14:38 UTC (permalink / raw)
To: rms, Alfred M. Szmidt; +Cc: eric, emacs-devel, spwhitton
Richard Stallman <rms@gnu.org> writes:
> > Since Magit is a VC like mode, wouldn't it make more sense to put it
> > under C-x v? E.g., why cannot Magit rebind C-x v l -- which I guess
> > is similar to magit-status or possibly C-x v d.
>
> I think you are suggesting that the key C-x v could be used both by VC
> and by Magit. That could make sense, if users generally use one or
> the other.
I use both, as they are good for different things.
I'd prefer to have `C-x v' be vc only to avoid any confusion.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-11 14:38 ` Stefan Kangas
@ 2021-02-11 15:13 ` Robert Pluim
2021-02-11 16:08 ` Stefan Monnier
0 siblings, 1 reply; 160+ messages in thread
From: Robert Pluim @ 2021-02-11 15:13 UTC (permalink / raw)
To: Stefan Kangas; +Cc: eric, Alfred M. Szmidt, spwhitton, rms, emacs-devel
>>>>> On Thu, 11 Feb 2021 08:38:21 -0600, Stefan Kangas <stefankangas@gmail.com> said:
Stefan> Richard Stallman <rms@gnu.org> writes:
>> > Since Magit is a VC like mode, wouldn't it make more sense to put it
>> > under C-x v? E.g., why cannot Magit rebind C-x v l -- which I guess
>> > is similar to magit-status or possibly C-x v d.
>>
>> I think you are suggesting that the key C-x v could be used both by VC
>> and by Magit. That could make sense, if users generally use one or
>> the other.
Stefan> I use both, as they are good for different things.
Stefan> I'd prefer to have `C-x v' be vc only to avoid any confusion.
+1
vc and Magit are two completely separate things to me (even though I
do use vc to do git stuff as well).
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-11 15:13 ` Robert Pluim
@ 2021-02-11 16:08 ` Stefan Monnier
2021-02-12 8:21 ` Alfred M. Szmidt
0 siblings, 1 reply; 160+ messages in thread
From: Stefan Monnier @ 2021-02-11 16:08 UTC (permalink / raw)
To: Robert Pluim
Cc: rms, eric, emacs-devel, Alfred M. Szmidt, Stefan Kangas,
spwhitton
> vc and Magit are two completely separate things to me (even though I
> do use vc to do git stuff as well).
Most of Magit's commands don't need to be bound globally anyway.
But I think it's best to think of `C-x v` in the same way as for
`lisp/vc`: it's not about the VC package but about the wider notion of
version control.
Stefan
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-11 16:08 ` Stefan Monnier
@ 2021-02-12 8:21 ` Alfred M. Szmidt
2021-02-12 8:36 ` Robert Pluim
0 siblings, 1 reply; 160+ messages in thread
From: Alfred M. Szmidt @ 2021-02-12 8:21 UTC (permalink / raw)
To: Stefan Monnier; +Cc: rms, eric, rpluim, emacs-devel, stefankangas, spwhitton
> vc and Magit are two completely separate things to me (even though I
> do use vc to do git stuff as well).
Most of Magit's commands don't need to be bound globally anyway.
Then it makes even more sense to just pick a key under C-x v.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-12 8:21 ` Alfred M. Szmidt
@ 2021-02-12 8:36 ` Robert Pluim
2021-02-12 15:11 ` Alfred M. Szmidt
2021-02-13 3:26 ` Richard Stallman
0 siblings, 2 replies; 160+ messages in thread
From: Robert Pluim @ 2021-02-12 8:36 UTC (permalink / raw)
To: Alfred M. Szmidt
Cc: rms, eric, stefankangas, emacs-devel, Stefan Monnier, spwhitton
>>>>> On Fri, 12 Feb 2021 03:21:49 -0500, "Alfred M. Szmidt" <ams@gnu.org> said:
>> vc and Magit are two completely separate things to me (even though I
>> do use vc to do git stuff as well).
Alfred> Most of Magit's commands don't need to be bound globally anyway.
Alfred> Then it makes even more sense to just pick a key under C-x v.
I donʼt follow. Magit is used for magit stuff, from the magit-status
window. If people want to use magit commands from other places, they
can choose their own binding or use the magit recommended ones.
vc is for abstracting away the differences between different version
control systems, why would magit commands need to share a prefix with
it?
Robert
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-12 8:36 ` Robert Pluim
@ 2021-02-12 15:11 ` Alfred M. Szmidt
2021-02-13 3:26 ` Richard Stallman
1 sibling, 0 replies; 160+ messages in thread
From: Alfred M. Szmidt @ 2021-02-12 15:11 UTC (permalink / raw)
To: Robert Pluim; +Cc: rms, eric, stefankangas, emacs-devel, monnier, spwhitton
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]
>> vc and Magit are two completely separate things to me (even though I
>> do use vc to do git stuff as well).
Alfred> Most of Magit's commands don't need to be bound globally anyway.
Alfred> Then it makes even more sense to just pick a key under C-x v.
I donʼt follow. Magit is used for magit stuff, from the magit-status
window. If people want to use magit commands from other places, they
can choose their own binding or use the magit recommended ones.
"magit stuff" is version control.
vc is for abstracting away the differences between different
version control systems, why would magit commands need to share a
prefix with it?
'C-x v .' (e.g.) could be bound to an alternative viewer function that
would work depending on the repository, e.g., gitk for those who wish
to use that, kick of a URL action for viewing a fossil repository
using "fossil ui", or whatever.
See how this is a much more general solution to work with _any_
"viewer" (whatever you wanna call magit) than having it take up
keybindings that could be put to a much more general use than a
specialzied one.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-12 8:36 ` Robert Pluim
2021-02-12 15:11 ` Alfred M. Szmidt
@ 2021-02-13 3:26 ` Richard Stallman
1 sibling, 0 replies; 160+ messages in thread
From: Richard Stallman @ 2021-02-13 3:26 UTC (permalink / raw)
To: Robert Pluim; +Cc: eric, stefankangas, emacs-devel, ams, monnier, spwhitton
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> vc is for abstracting away the differences between different version
> control systems, why would magit commands need to share a prefix with
> it?
I did not say they "need" to. But if we are short of places to put
things, putting two things both related to version control, which
people don't use together, on a single key sequence could work well.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 5:28 ` Richard Stallman
2021-02-10 9:29 ` Thibaut Verron
2021-02-10 10:42 ` Alfred M. Szmidt
@ 2021-02-10 11:07 ` Gregory Heytings
2021-02-10 13:00 ` Alfred M. Szmidt
2021-02-11 13:37 ` Richard Stallman
2 siblings, 2 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-10 11:07 UTC (permalink / raw)
To: Richard Stallman; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]
>
> Suppose we reserve one key for third-party packages. Let's refer to
> that key as C-α, to avoid specifying which key is chosen.
>
> Various packages will set up their own bindings for it. If you load
> more than one such package, which package's bindings will you get? How
> do you get the ones you want?
>
This is something that should be left to packages. Org-mode would bind,
say, C-α a, C-α c and C-α l, or perhaps C-α o a, C-α o c and C-α o l;
Magit would bind C-α g and C-α M-g, or perhaps C-α g g and C-α g f; and so
forth. There will be conflicts, of course, but only occasionally, and in
those cases users would have to do something to resolve the conflict.
>
> Here's an idea.
>
> Have one command you can use to specify which package's bindings C-α
> will run. It could be C-α C-α; then individual packages will not give
> their own bindings for C-α C-α.
>
> So you can type C-α C-α Foopkg RET, then C-α gives you the Foopkg
> bindings.
>
I'm not sure I understand what you mean. Would this mean that each time
you want to use, say, Org-mode you would have to C-α C-α org-mode RET
before typing C-α c? If so, I don't think this would work.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 11:07 ` Gregory Heytings
@ 2021-02-10 13:00 ` Alfred M. Szmidt
2021-02-10 13:59 ` Gregory Heytings
2021-02-11 13:37 ` Richard Stallman
1 sibling, 1 reply; 160+ messages in thread
From: Alfred M. Szmidt @ 2021-02-10 13:00 UTC (permalink / raw)
To: Gregory Heytings; +Cc: rms, emacs-devel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]
> Suppose we reserve one key for third-party packages. Let's refer to
> that key as C-α, to avoid specifying which key is chosen.
>
> Various packages will set up their own bindings for it. If you load
> more than one such package, which package's bindings will you get? How
> do you get the ones you want?
This is something that should be left to packages. Org-mode would bind,
say, C-α a, C-α c and C-α l, or perhaps C-α o a, C-α o c and C-α o l;
Magit would bind C-α g and C-α M-g, or perhaps C-α g g and C-α g f; and so
forth. There will be conflicts, of course, but only occasionally, and in
those cases users would have to do something to resolve the conflict.
Wasn't C-? supposed to be a global keybinding? org-mode speciic
bindings don't make sense outside of org-mode and mode specific
keybindings already have a set that is already reserved for them. The
issue as I understood it was that there are some modes that have
bindings that make sense in a global context -- e.g., Magit
vs. vc-mode where the specific mode of the buffer doesn't matter.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 13:00 ` Alfred M. Szmidt
@ 2021-02-10 13:59 ` Gregory Heytings
2021-02-10 14:10 ` Alfred M. Szmidt
0 siblings, 1 reply; 160+ messages in thread
From: Gregory Heytings @ 2021-02-10 13:59 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: emacs-devel
>>> Suppose we reserve one key for third-party packages. Let's refer to
>>> that key as C-\alpha, to avoid specifying which key is chosen.
>>>
>>> Various packages will set up their own bindings for it. If you load
>>> more than one such package, which package's bindings will you get? How
>>> do you get the ones you want?
>>
>> This is something that should be left to packages. Org-mode would
>> bind, say, C-\alpha a, C-\alpha c and C-\alpha l, or perhaps C-\alpha o
>> a, C-\alpha o c and C-\alpha o l; Magit would bind C-\alpha g and
>> C-\alpha M-g, or perhaps C-\alpha g g and C-\alpha g f; and so forth.
>> There will be conflicts, of course, but only occasionally, and in those
>> cases users would have to do something to resolve the conflict.
>
> Wasn't C-\alpha supposed to be a global keybinding? org-mode speciic
> bindings don't make sense outside of org-mode and mode specific
> keybindings already have a set that is already reserved for them.
>
Org-mode has indeed its own bindings when you are in an org-mode buffer,
but three of its commands make sense / are designed to be used outside of
org-mode buffers: org-agenda, org-capture and org-store-link.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 13:59 ` Gregory Heytings
@ 2021-02-10 14:10 ` Alfred M. Szmidt
2021-02-10 14:51 ` Gregory Heytings
0 siblings, 1 reply; 160+ messages in thread
From: Alfred M. Szmidt @ 2021-02-10 14:10 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
> Wasn't C-\alpha supposed to be a global keybinding? org-mode speciic
> bindings don't make sense outside of org-mode and mode specific
> keybindings already have a set that is already reserved for them.
Org-mode has indeed its own bindings when you are in an org-mode buffer,
but three of its commands make sense / are designed to be used outside of
org-mode buffers: org-agenda, org-capture and org-store-link.
So just random thinking, since we have calendar mode, and diary mode.
And those do not have a global binding, why should
org-agenda/org-capture/org-store-link get one?
Or why not put org-store-link under C-x r ? This seems similar enough
to "bookmarks", capture might even also fit there. Agenda, too if you
squint I suppose -- or an alias M-x agenda.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 14:10 ` Alfred M. Szmidt
@ 2021-02-10 14:51 ` Gregory Heytings
2021-02-10 15:12 ` Alfred M. Szmidt
0 siblings, 1 reply; 160+ messages in thread
From: Gregory Heytings @ 2021-02-10 14:51 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: emacs-devel
>>> Wasn't C-\alpha supposed to be a global keybinding? org-mode speciic
>>> bindings don't make sense outside of org-mode and mode specific
>>> keybindings already have a set that is already reserved for them.
>>
>> Org-mode has indeed its own bindings when you are in an org-mode
>> buffer, but three of its commands make sense / are designed to be used
>> outside of org-mode buffers: org-agenda, org-capture and
>> org-store-link.
>
> So just random thinking, since we have calendar mode, and diary mode.
> And those do not have a global binding, why should
> org-agenda/org-capture/org-store-link get one?
>
Because someone who installs Emacs does not (in general) do that with the
specific intention of using calendar mode or diary mode, whereas someone
who installs org-mode does it with the specific intention of using
org-mode?
That being said, I would not object if Emacs decided to give a global
binding to some of the built-in apps (calendar, calc, gnus, diary, ...).
>
> Or why not put org-store-link under C-x r ?
>
That would be possible, but there are not many free letters there, and if
org-mode did this it would take the risk to have the chosen key reclaimed
by Emacs for another purpose at any time.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 14:51 ` Gregory Heytings
@ 2021-02-10 15:12 ` Alfred M. Szmidt
2021-02-10 15:23 ` Gregory Heytings
0 siblings, 1 reply; 160+ messages in thread
From: Alfred M. Szmidt @ 2021-02-10 15:12 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
> Or why not put org-store-link under C-x r ?
That would be possible, but there are not many free letters there, and if
org-mode did this it would take the risk to have the chosen key reclaimed
by Emacs for another purpose at any time.
But org-mode is part of Emacs...
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 15:12 ` Alfred M. Szmidt
@ 2021-02-10 15:23 ` Gregory Heytings
0 siblings, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-10 15:23 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: emacs-devel
>>> Or why not put org-store-link under C-x r ?
>>
>> That would be possible, but there are not many free letters there, and
>> if org-mode did this it would take the risk to have the chosen key
>> reclaimed by Emacs for another purpose at any time.
>
> But org-mode is part of Emacs...
>
Org-mode is an exception indeed, it is both part of Emacs and an external
package on Elpa. As you may have seen, the proposal is not only for
org-mode, it is for third-party libraries in general.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-10 11:07 ` Gregory Heytings
2021-02-10 13:00 ` Alfred M. Szmidt
@ 2021-02-11 13:37 ` Richard Stallman
2021-02-11 13:55 ` Gregory Heytings
1 sibling, 1 reply; 160+ messages in thread
From: Richard Stallman @ 2021-02-11 13:37 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > So you can type C-α C-α Foopkg RET, then C-α gives you the Foopkg
> > bindings.
> >
> I'm not sure I understand what you mean. Would this mean that each time
> you want to use, say, Org-mode you would have to C-α C-α org-mode RET
> before typing C-α c? If so, I don't think this would work.
Org is a collection of major modes, so I don't think it should need to
use the C-α mechanism. That mechanism would be meant for packages
that need to define a binding for a global prefix key. Major modes
can simply define local bindings.
> Org-mode also binds keys (at least one) globally
> that (AFAIK) cannot possibly have a use outside
> of an org-mode buffer.
Perhaps they should be changed into local (major mode) bindings.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-11 13:37 ` Richard Stallman
@ 2021-02-11 13:55 ` Gregory Heytings
0 siblings, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-11 13:55 UTC (permalink / raw)
To: Richard Stallman; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]
>>> So you can type C-α C-α Foopkg RET, then C-α gives you the Foopkg
>>> bindings.
>>
>> I'm not sure I understand what you mean. Would this mean that each
>> time you want to use, say, Org-mode you would have to C-α C-α org-mode
>> RET before typing C-α c? If so, I don't think this would work.
>
> Org is a collection of major modes, so I don't think it should need to
> use the C-α mechanism. That mechanism would be meant for packages that
> need to define a binding for a global prefix key. Major modes can
> simply define local bindings.
>
Org is indeed a collection of major modes, but three of its commands are
meant to be bound to global bindings: org-capture, org-agenda, and
org-store-link. These commands are intended to be called from anywhere
else, say from Rmail. For example, org-capture is similar to (and derived
from) M-x remember, it lets you store notes without interrupting your work
flow: while reading a mail in Rmail you can select a part of its text and
call org-capture, the text you selected will be copied to a new note, you
can add other information to the note, and the result will be stored in
your "notes.org" file.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 16:45 ` Sean Whitton
2021-02-10 5:28 ` Richard Stallman
@ 2021-02-12 9:40 ` Jean Louis
1 sibling, 0 replies; 160+ messages in thread
From: Jean Louis @ 2021-02-12 9:40 UTC (permalink / raw)
To: Sean Whitton; +Cc: Eric Abrahamsen, emacs-devel
* Sean Whitton <spwhitton@spwhitton.name> [2021-02-09 19:45]:
> Hello,
>
> On Mon 08 Feb 2021 at 02:40PM -08, Eric Abrahamsen wrote:
>
> > If C-x C-z is already `suspend-frame', do we really need C-z C-z, too?
>
> As has been mentioned, the thought is that a terminal user who doesn't
> know much about Emacs will probably just hit it a second time if it
> doesn't do what they expect.
I use C-z in shell to stop the job and those jobs usually on my side
impact performance of the computer or performance of the other
job. Imagine the surprise when C-z does not work as expected, will the
user make conclusion to press C-z again after 1 second or after 20 or
30 seconds, and will the data on computer be preserved until that
conclusion arrives? I don't think so.
Removing C-z on console is dangerous for data of computer users IMHO.
Removing C-z on X has less impact on the computer users' data, but
helps user to switch from one frame (iconified) to something else.
Jean
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-07 22:05 Gregory Heytings
` (6 preceding siblings ...)
2021-02-08 17:59 ` Sean Whitton
@ 2021-02-08 20:32 ` Ulrich Mueller
2021-02-08 21:00 ` Gregory Heytings
[not found] ` <8735y56naf.fsf@posteo.net>
8 siblings, 1 reply; 160+ messages in thread
From: Ulrich Mueller @ 2021-02-08 20:32 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
>>>>> On Sun, 07 Feb 2021, Gregory Heytings wrote:
> =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 don't. C-z is bound to "suspend" since a very long time (it's
even mentioned in Craig Finseth's book), and it is one of the few keys
that has an universal meaning on the tty in Unix like systems, across
applications.
Also, it would be a large pain to use anything other than a single key
for this function.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 20:32 ` Ulrich Mueller
@ 2021-02-08 21:00 ` Gregory Heytings
2021-02-08 21:37 ` Ulrich Mueller
0 siblings, 1 reply; 160+ messages in thread
From: Gregory Heytings @ 2021-02-08 21:00 UTC (permalink / raw)
To: Ulrich Mueller; +Cc: emacs-devel
>> 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 don't. C-z is bound to "suspend" since a very long time (it's
> even mentioned in Craig Finseth's book), and it is one of the few keys
> that has an universal meaning on the tty in Unix like systems, across
> applications.
>
> Also, it would be a large pain to use anything other than a single key
> for this function.
>
Do you really mean that it is "a large pain" to type "C-z C-z" (three
keypresses) instead of "C-z" (two keypresses)? For something you don't do
frequently?
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 21:00 ` Gregory Heytings
@ 2021-02-08 21:37 ` Ulrich Mueller
2021-02-08 22:00 ` Gregory Heytings
2021-02-09 16:57 ` Sean Whitton
0 siblings, 2 replies; 160+ messages in thread
From: Ulrich Mueller @ 2021-02-08 21:37 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
>>>>> On Mon, 08 Feb 2021, Gregory Heytings wrote:
>>> 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 don't. C-z is bound to "suspend" since a very long time (it's
>> even mentioned in Craig Finseth's book), and it is one of the few
>> keys that has an universal meaning on the tty in Unix like systems,
>> across applications.
>>
>> Also, it would be a large pain to use anything other than a single
>> key for this function.
> Do you really mean that it is "a large pain" to type "C-z C-z" (three
> keypresses) instead of "C-z" (two keypresses)? For something you don't
> do frequently?
I'd say that at least on a tty I use C-z more frequently than several
other control keys.
How about C-\ or C-^? Historically these were used as substitutes for
C-s and C-q when editing via serial lines (and there's still a function
enable-flow-control that activates it). Certainly that's no longer a
frequent use case?
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 21:37 ` Ulrich Mueller
@ 2021-02-08 22:00 ` Gregory Heytings
2021-02-09 16:57 ` Sean Whitton
1 sibling, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-08 22:00 UTC (permalink / raw)
To: Ulrich Mueller; +Cc: emacs-devel
>> Do you really mean that it is "a large pain" to type "C-z C-z" (three
>> keypresses) instead of "C-z" (two keypresses)? For something you don't
>> do frequently?
>
> I'd say that at least on a tty I use C-z more frequently than several
> other control keys.
>
So do I, but that still doesn't make it "a large pain" to type "C-z C-z"
instead of "C-z", I guess.
>
> How about C-\ or C-^?
>
I did consider to include C-\ in the options, but \ is hard to type on
most keyboards: C and \ are the two most distant keys on the most
widespread keyboard layout (QWERTY), on other keyboards \ requires
pressing Shift or AltGr, ... A letter would be much better.
C-^ is clearly not an option, it is way too hard to type even with the
QWERTY layout (C-S-6).
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-08 21:37 ` Ulrich Mueller
2021-02-08 22:00 ` Gregory Heytings
@ 2021-02-09 16:57 ` Sean Whitton
2021-02-09 17:19 ` Gregory Heytings
1 sibling, 1 reply; 160+ messages in thread
From: Sean Whitton @ 2021-02-09 16:57 UTC (permalink / raw)
To: Ulrich Mueller, Gregory Heytings; +Cc: emacs-devel
Hello,
On Mon 08 Feb 2021 at 10:37PM +01, Ulrich Mueller wrote:
> How about C-\ or C-^? Historically these were used as substitutes for
> C-s and C-q when editing via serial lines (and there's still a function
> enable-flow-control that activates it). Certainly that's no longer a
> frequent use case?
C-\ is used to set the input method. But we could move that
functionality to C-^, and then give up C-\ to third party packages.
--
Sean Whitton
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 16:57 ` Sean Whitton
@ 2021-02-09 17:19 ` Gregory Heytings
2021-02-09 17:59 ` Ulrich Mueller
` (2 more replies)
0 siblings, 3 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-09 17:19 UTC (permalink / raw)
To: Sean Whitton; +Cc: emacs-devel
>> How about C-\ or C-^? Historically these were used as substitutes for
>> C-s and C-q when editing via serial lines (and there's still a function
>> enable-flow-control that activates it). Certainly that's no longer a
>> frequent use case?
>
> C-\ is used to set the input method. But we could move that
> functionality to C-^, and then give up C-\ to third party packages.
>
Except that \ is hard to type on most keyboards: C and \ are the two most
distant keys on the most widespread keyboard layout (QWERTY), and on other
keyboards \ requires pressing Shift or AltGr. Not exactly an appealing
prefix.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 17:19 ` Gregory Heytings
@ 2021-02-09 17:59 ` Ulrich Mueller
2021-02-09 18:24 ` Gregory Heytings
2021-02-09 18:19 ` Thibaut Verron
2021-02-09 21:34 ` Sean Whitton
2 siblings, 1 reply; 160+ messages in thread
From: Ulrich Mueller @ 2021-02-09 17:59 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel, Sean Whitton
>>>>> On Tue, 09 Feb 2021, Gregory Heytings wrote:
>>> How about C-\ or C-^? Historically these were used as substitutes
>>> for C-s and C-q when editing via serial lines (and there's still a
>>> function enable-flow-control that activates it). Certainly that's
>>> no longer a frequent use case?
>>
>> C-\ is used to set the input method. But we could move that
>> functionality to C-^, and then give up C-\ to third party packages.
> Except that \ is hard to type on most keyboards: C and \ are the two
> most distant keys on the most widespread keyboard layout (QWERTY), and
> on other keyboards \ requires pressing Shift or AltGr. Not exactly an
> appealing prefix.
The same could be said for C-o or M-o. And if you care about non-QWERTY
layouts, C-z on a German QWERTZ keyboard isn't much better.
(Also I wonder, aren't Shift, Ctrl, and Alt keys meant to be used
crosswise, i.e., left key for the right half of the keyboard, and vice
versa? For example, how do you type C-b or C-t?)
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 17:59 ` Ulrich Mueller
@ 2021-02-09 18:24 ` Gregory Heytings
0 siblings, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-09 18:24 UTC (permalink / raw)
To: Ulrich Mueller; +Cc: emacs-devel
>>> C-\ is used to set the input method. But we could move that
>>> functionality to C-^, and then give up C-\ to third party packages.
>>
>> Except that \ is hard to type on most keyboards: C and \ are the two
>> most distant keys on the most widespread keyboard layout (QWERTY), and
>> on other keyboards \ requires pressing Shift or AltGr. Not exactly an
>> appealing prefix.
>
> The same could be said for C-o or M-o. And if you care about non-QWERTY
> layouts, C-z on a German QWERTZ keyboard isn't much better.
>
At least these are letters, which do not require pressing Shift or AltGr
anywhere. Nothing is perfect, it's a practical problem, and "o" and "z"
are the only letters that have a non-zero chance to be repurposed.
>
> (Also I wonder, aren't Shift, Ctrl, and Alt keys meant to be used
> crosswise, i.e., left key for the right half of the keyboard, and vice
> versa? For example, how do you type C-b or C-t?)
>
That depends on your keyboard, not all keyboards have two Ctrl keys and
two Meta/Alt keys. I remapped Caps Lock to Ctrl, and have my left pinkie
almost always resting on it.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 17:19 ` Gregory Heytings
2021-02-09 17:59 ` Ulrich Mueller
@ 2021-02-09 18:19 ` Thibaut Verron
2021-02-09 19:16 ` Gregory Heytings
2021-02-09 22:19 ` Gregory Heytings
2021-02-09 21:34 ` Sean Whitton
2 siblings, 2 replies; 160+ messages in thread
From: Thibaut Verron @ 2021-02-09 18:19 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel, Sean Whitton
2021-02-09 18:19 UTC+01:00, Gregory Heytings <gregory@heytings.org>:
>
>>> How about C-\ or C-^? Historically these were used as substitutes for
>>> C-s and C-q when editing via serial lines (and there's still a function
>>> enable-flow-control that activates it). Certainly that's no longer a
>>> frequent use case?
>>
>> C-\ is used to set the input method. But we could move that
>> functionality to C-^, and then give up C-\ to third party packages.
>>
>
> Except that \ is hard to type on most keyboards: C and \ are the two most
> distant keys on the most widespread keyboard layout (QWERTY), and on other
> keyboards \ requires pressing Shift or AltGr.
I don't quite get how you reach that conclusion about the qwerty keyboard.
On my ISO102 qwerty keyboard, \ is diagonally adjacent to left control
(regardless of whether it's at its original position or on capslock),
and there is another \ left of RET, so two keys above, one left of
right control.
With an ANSI keyboard, it's only available on one key, which is 3 keys
above right control.
So in both cases, I don't think it qualifies as "the most distant key"
from control. To the contrary, I'd say that it is too close to it to
be comfortable to type if you don't use different hands for modifier
and key.
And while \ indeed is a pain to type on non-qwerty layouts, on an
azerty keyboard, the corresponding keys are < and *, both of which are
free with a C- modifier.
On a qwertz it's < and $, which again are free with a C- modifier.
(Those are the keyboards I can look at here, I don't know how it generalizes.)
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 18:19 ` Thibaut Verron
@ 2021-02-09 19:16 ` Gregory Heytings
2021-02-09 19:28 ` Thibaut Verron
2021-02-09 19:47 ` Stefan Monnier
2021-02-09 22:19 ` Gregory Heytings
1 sibling, 2 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-09 19:16 UTC (permalink / raw)
To: Thibaut Verron; +Cc: emacs-devel
>> Except that \ is hard to type on most keyboards: C and \ are the two
>> most distant keys on the most widespread keyboard layout (QWERTY), and
>> on other keyboards \ requires pressing Shift or AltGr.
>
> I don't quite get how you reach that conclusion about the qwerty
> keyboard.
>
> On my ISO102 qwerty keyboard, \ is diagonally adjacent to left control
> (regardless of whether it's at its original position or on capslock),
> and there is another \ left of RET, so two keys above, one left of right
> control.
>
> With an ANSI keyboard, it's only available on one key, which is 3 keys
> above right control.
>
This is diverging more and more from the proposal, but: on smaller
keyboards (laptops) there is typically only one control key (on the bottom
left) and only \ key (near the right top).
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 19:16 ` Gregory Heytings
@ 2021-02-09 19:28 ` Thibaut Verron
2021-02-09 20:15 ` Gregory Heytings
2021-02-09 19:47 ` Stefan Monnier
1 sibling, 1 reply; 160+ messages in thread
From: Thibaut Verron @ 2021-02-09 19:28 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
2021-02-09 20:16 UTC+01:00, Gregory Heytings <gregory@heytings.org>:
>
>>> Except that \ is hard to type on most keyboards: C and \ are the two
>>> most distant keys on the most widespread keyboard layout (QWERTY), and
>>> on other keyboards \ requires pressing Shift or AltGr.
>>
>> I don't quite get how you reach that conclusion about the qwerty
>> keyboard.
>>
>> On my ISO102 qwerty keyboard, \ is diagonally adjacent to left control
>> (regardless of whether it's at its original position or on capslock),
>> and there is another \ left of RET, so two keys above, one left of right
>> control.
>>
>> With an ANSI keyboard, it's only available on one key, which is 3 keys
>> above right control.
>>
>
> This is diverging more and more from the proposal, but: on smaller
> keyboards (laptops) there is typically only one control key (on the bottom
> left) and only \ key (near the right top).
>
I cannot remember ever laying my hands on a laptop with only one
control key, but that may be one more of those ISO vs ANSI things.
At any rate, it's far easier to type C-\ with the left hand on control
and right hand on \ than both with the right hand. The fact that your
left control is on capslock (mine is, too) shouldn't make a
difference: left pinky on control/capslock, right pinky on \.
Do you also find C-ret or C-backspace hard to type?
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 19:28 ` Thibaut Verron
@ 2021-02-09 20:15 ` Gregory Heytings
0 siblings, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-09 20:15 UTC (permalink / raw)
To: Thibaut Verron; +Cc: emacs-devel
>
> Do you also find C-ret or C-backspace hard to type?
>
C-\ or M-\, or C-RET or M-RET, are perhaps not "hard to type" by
themselves on keyboards that do not require pressing another modifier, but
as a prefix, followed by another letter, or C-letter, or M-letter, they
would. You have to move your hands too much. It can't be an appealing
solution for third-party libraries.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 19:16 ` Gregory Heytings
2021-02-09 19:28 ` Thibaut Verron
@ 2021-02-09 19:47 ` Stefan Monnier
1 sibling, 0 replies; 160+ messages in thread
From: Stefan Monnier @ 2021-02-09 19:47 UTC (permalink / raw)
To: Gregory Heytings; +Cc: Thibaut Verron, emacs-devel
> This is diverging more and more from the proposal, but: on smaller keyboards
> (laptops) there is typically only one control key (on the bottom left) and
> only \ key (near the right top).
And I don't own a "non-small keyboard" any more, and judging from
people around me, I'm far from the only one.
Stefan
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 18:19 ` Thibaut Verron
2021-02-09 19:16 ` Gregory Heytings
@ 2021-02-09 22:19 ` Gregory Heytings
1 sibling, 0 replies; 160+ messages in thread
From: Gregory Heytings @ 2021-02-09 22:19 UTC (permalink / raw)
To: Thibaut Verron; +Cc: emacs-devel
>
> And while \ indeed is a pain to type on non-qwerty layouts, on an azerty
> keyboard, the corresponding keys are < and *, both of which are free
> with a C- modifier. On a qwertz it's < and $, which again are free with
> a C- modifier.
>
I forgot to mention that these keys are indeed free, but do not work in a
terminal.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
2021-02-09 17:19 ` Gregory Heytings
2021-02-09 17:59 ` Ulrich Mueller
2021-02-09 18:19 ` Thibaut Verron
@ 2021-02-09 21:34 ` Sean Whitton
2 siblings, 0 replies; 160+ messages in thread
From: Sean Whitton @ 2021-02-09 21:34 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
Hello,
On Tue 09 Feb 2021 at 05:19PM GMT, Gregory Heytings wrote:
>>> How about C-\ or C-^? Historically these were used as substitutes for
>>> C-s and C-q when editing via serial lines (and there's still a function
>>> enable-flow-control that activates it). Certainly that's no longer a
>>> frequent use case?
>>
>> C-\ is used to set the input method. But we could move that
>> functionality to C-^, and then give up C-\ to third party packages.
>>
>
> Except that \ is hard to type on most keyboards: C and \ are the two most
> distant keys on the most widespread keyboard layout (QWERTY), and on other
> keyboards \ requires pressing Shift or AltGr. Not exactly an appealing
> prefix.
Hmm, if you're using two hands for the C and the \ and you're on QWERTY
then it's not too bad.
Should we be trying to take into account other layouts, given that most
of Emacs' default bindings are designed for a keyboard which doesn't
even exist anymore (Space Cadet)?
ISTM that we are only rarely going to find options which are optimum for
all layouts at once, so maybe we should expect users of those layouts to
move hard things around (and that moving around could be included in
Emacs).
--
Sean Whitton
^ permalink raw reply [flat|nested] 160+ messages in thread
[parent not found: <8735y56naf.fsf@posteo.net>]
end of thread, other threads:[~2021-02-15 19:55 UTC | newest]
Thread overview: 160+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-02-08 10:02 PROPOSAL: Repurpose one key and reserve it for third-party packages Gregory Heytings
2021-02-08 16:41 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-08 22:01 ` Francis Belliveau
2021-02-09 0:05 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-09 8:36 ` "Windows" key [was: Repurpose one key and reserve it for third-party] packages tomas
2021-02-10 22:54 ` PROPOSAL: Repurpose one key and reserve it for third-party packages Francis Belliveau
2021-02-09 6:31 ` Jean Louis
2021-02-09 9:13 ` Gregory Heytings
2021-02-10 11:17 ` Jean Louis
2021-02-09 17:13 ` [External] : " Drew Adams
2021-02-09 17:49 ` Gregory Heytings
2021-02-09 18:12 ` Drew Adams
2021-02-09 19:23 ` Gregory Heytings
2021-02-09 20:52 ` [External] : " Drew Adams
2021-02-09 21:15 ` Gregory Heytings
2021-02-09 21:47 ` [External] : " Drew Adams
2021-02-09 22:06 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-09 22:58 ` Drew Adams
2021-02-09 23:23 ` Drew Adams
2021-02-09 23:48 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-10 11:07 ` Gregory Heytings
2021-02-10 9:05 ` Robert Thorpe
2021-02-10 14:42 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-10 14:59 ` Gregory Heytings
2021-02-10 11:33 ` [External] : " Jean Louis
2021-02-10 11:41 ` Thibaut Verron
2021-02-10 15:29 ` Eli Zaretskii
2021-02-10 11:30 ` Jean Louis
2021-02-09 8:13 ` Marcin Borkowski
2021-02-09 9:13 ` Gregory Heytings
-- strict thread matches above, loose matches on Subject: below --
2021-02-15 19:01 Gregory Heytings
2021-02-15 19:55 ` Dmitry Gutov
2021-02-07 22:05 Gregory Heytings
2021-02-08 0:13 ` Ergus
2021-02-08 2:57 ` Jorge Javier Araya Navarro
2021-02-08 3:46 ` Richard Stallman
2021-02-08 7:20 ` Stefan Kangas
2021-02-08 14:58 ` Lars Ingebrigtsen
2021-02-08 21:00 ` Gregory Heytings
2021-02-08 21:33 ` Stefan Monnier
2021-02-09 8:13 ` Lars Ingebrigtsen
2021-02-09 16:54 ` Sean Whitton
2021-02-09 17:13 ` Lars Ingebrigtsen
2021-02-09 17:43 ` Eli Zaretskii
2021-02-09 21:21 ` Sean Whitton
2021-02-09 18:37 ` Stefan Monnier
2021-02-08 22:45 ` Stefan Kangas
2021-02-08 15:45 ` Thibaut Verron
2021-02-08 23:01 ` Stefan Kangas
2021-02-09 9:13 ` Simen Heggestøyl
2021-02-09 9:30 ` Juri Linkov
2021-02-09 13:01 ` Gregory Heytings
2021-02-08 21:00 ` Gregory Heytings
2021-02-09 6:03 ` Richard Stallman
2021-02-08 12:36 ` Alan Mackenzie
2021-02-08 21:00 ` Gregory Heytings
2021-02-08 4:52 ` Robin Tarsiger
2021-02-08 8:41 ` Thibaut Verron
2021-02-08 17:07 ` Robin Tarsiger
2021-02-11 12:59 ` Arthur Miller
2021-02-08 21:00 ` Gregory Heytings
2021-02-09 7:42 ` Yuri Khan
2021-02-09 8:23 ` Gregory Heytings
2021-02-08 23:14 ` Stefan Monnier
2021-02-09 8:23 ` Gregory Heytings
2021-02-08 12:42 ` Augusto Stoffel
2021-02-08 21:00 ` Gregory Heytings
2021-02-08 14:54 ` Dmitry Gutov
2021-02-08 21:00 ` Gregory Heytings
2021-02-08 17:59 ` Sean Whitton
2021-02-08 22:40 ` Eric Abrahamsen
2021-02-09 16:45 ` Sean Whitton
2021-02-10 5:28 ` Richard Stallman
2021-02-10 9:29 ` Thibaut Verron
2021-02-11 13:37 ` Richard Stallman
2021-02-11 13:52 ` Thibaut Verron
2021-02-10 10:42 ` Alfred M. Szmidt
2021-02-10 11:35 ` Thibaut Verron
2021-02-10 12:59 ` Alfred M. Szmidt
2021-02-11 13:37 ` Richard Stallman
2021-02-11 14:38 ` Stefan Kangas
2021-02-11 15:13 ` Robert Pluim
2021-02-11 16:08 ` Stefan Monnier
2021-02-12 8:21 ` Alfred M. Szmidt
2021-02-12 8:36 ` Robert Pluim
2021-02-12 15:11 ` Alfred M. Szmidt
2021-02-13 3:26 ` Richard Stallman
2021-02-10 11:07 ` Gregory Heytings
2021-02-10 13:00 ` Alfred M. Szmidt
2021-02-10 13:59 ` Gregory Heytings
2021-02-10 14:10 ` Alfred M. Szmidt
2021-02-10 14:51 ` Gregory Heytings
2021-02-10 15:12 ` Alfred M. Szmidt
2021-02-10 15:23 ` Gregory Heytings
2021-02-11 13:37 ` Richard Stallman
2021-02-11 13:55 ` Gregory Heytings
2021-02-12 9:40 ` Jean Louis
2021-02-08 20:32 ` Ulrich Mueller
2021-02-08 21:00 ` Gregory Heytings
2021-02-08 21:37 ` Ulrich Mueller
2021-02-08 22:00 ` Gregory Heytings
2021-02-09 16:57 ` Sean Whitton
2021-02-09 17:19 ` Gregory Heytings
2021-02-09 17:59 ` Ulrich Mueller
2021-02-09 18:24 ` Gregory Heytings
2021-02-09 18:19 ` Thibaut Verron
2021-02-09 19:16 ` Gregory Heytings
2021-02-09 19:28 ` Thibaut Verron
2021-02-09 20:15 ` Gregory Heytings
2021-02-09 19:47 ` Stefan Monnier
2021-02-09 22:19 ` Gregory Heytings
2021-02-09 21:34 ` Sean Whitton
[not found] ` <8735y56naf.fsf@posteo.net>
[not found] ` <8ed9b43502ae9a36b057@heytings.org>
2021-02-09 23:18 ` Philip K.
2021-02-10 11:07 ` Gregory Heytings
2021-02-10 23:35 ` Philip K.
2021-02-11 8:45 ` Gregory Heytings
2021-02-11 13:53 ` Philip K.
2021-02-11 15:47 ` Philip K.
2021-02-11 15:59 ` Gregory Heytings
2021-02-11 16:20 ` Philip K.
2021-02-11 17:48 ` Gregory Heytings
2021-02-11 18:34 ` Philip K.
2021-02-11 21:15 ` Gregory Heytings
2021-02-11 22:48 ` Philip K.
2021-02-12 0:01 ` Gregory Heytings
2021-02-12 10:27 ` Philip K.
2021-02-12 11:59 ` Gregory Heytings
2021-02-12 13:23 ` Philip K.
2021-02-12 13:54 ` Gregory Heytings
2021-02-12 14:09 ` Philip Kaludercic
2021-02-12 16:04 ` Gregory Heytings
2021-02-12 17:25 ` Philip Kaludercic
2021-02-12 17:54 ` Gregory Heytings
2021-02-12 18:16 ` Philip Kaludercic
2021-02-12 21:48 ` Gregory Heytings
2021-02-13 0:37 ` Philip Kaludercic
2021-02-13 8:33 ` Gregory Heytings
2021-02-13 9:09 ` Philip Kaludercic
2021-02-13 13:06 ` Gregory Heytings
2021-02-13 14:28 ` Philip Kaludercic
2021-02-13 15:01 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-13 16:08 ` Philip Kaludercic
2021-02-13 15:02 ` Gregory Heytings
2021-02-13 15:21 ` Jean Louis
2021-02-13 15:28 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-13 20:14 ` Philip Kaludercic
2021-02-13 20:58 ` Jean Louis
2021-02-13 21:18 ` Gregory Heytings
2021-02-13 21:32 ` Philip Kaludercic
2021-02-13 10:05 ` Jean Louis
2021-02-13 8:24 ` Jean Louis
2021-02-13 12:44 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-13 14:26 ` Jean Louis
2021-02-13 15:09 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-13 15:24 ` Jean Louis
2021-02-13 15:38 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-13 15:45 ` Jean Louis
2021-02-12 4:45 ` Robert Thorpe
2021-02-12 9:58 ` Philip K.
2021-02-11 16:59 ` Leo Butler
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.