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

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

[Gregory Heytings]

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

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

[Ergus]

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

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

[Jorge Javier Araya Navarro]

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

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

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

> =Proposal=
>
> It is proposed to repurpose one key, and to reserve it in the key binding
>
> conventions for third-party packages. The keys that could be reserved for
>
> that purpose are:
>
> Option 1. C-z, with a single exception: "C-z C-z" would be bound to
>
> "suspend-frame"
>
> Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound to
>
> "suspend-frame", and "M-z M-z" to "zap-to-char"
>
> Option 3. C-o, with a single exception: "C-o C-o" would be bound to
>
> "open-line"
>
> Option 4. C-o and M-o, with two exceptions: "C-o C-o" would be bound to
>
> "open-line", and "M-o M-o" to "facemenu-keymap"
>
> =Rationale=
>
> The current key binding conventions (see `(elisp) Key Binding
>
> Conventions') reserve keys for users, for major modes and for minor modes,
>
> but not for third-party packages [1].
>
> When such packages need to bind a command to a key, they can (1) either
>
> suggest users to bind it to a key reserved for users (for example,
>
> org-mode suggests to globally bind "C-c c" to org-capture), or (2) bind it
>
> to a key currently unused by Emacs (for example, Magit binds "C-x g" to
>
> magit-status in buffers visiting a file in a Git repository).
>
> Neither of these solutions are optimal: (1) requires an explicit
>
> configuration by the user, something which might confuse newcomers, and
>
> which other users might not want to do because they already use the keys
>
> reserved for users for other purposes, and (2) might conflict with the
>
> evolution of Emacs when one or more commands are bound to a yet unused
>
> key.
>
> Reserving one key for third-party packages solves the above problems:
>
> third-party packages can automatically bind a few keys in that reserved
>
> area, without conflicting with keys reserved for users and without
>
> conflicting with future Emacs evolutions.
>
> =Limit=
>
> Conflicts are still possible, when two or more packages bind the same
>
> keys. These are, however, conflicts between packages, not between a
>
> package and Emacs, or between a package and users' personal
>
> configurations.
>
> Such conflicts are also less likely for typical users, who install a few
>
> packages each binding a few keys.
>
> Finally, such conflicts can be dealt with without confusing users too
>
> much: a package could automatically choose fallback key bindings when the
>
> preferred ones are already used by another package, and/or issue a warning
>
> to the user that they need to bind its commands manually.
>
> =Note=
>
> [1] These conventions were written 25 years ago, at a time when there were
>
> far fewer third-party packages, and have not changed substantially since
>
> them.

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

[Richard Stallman]

[[[ 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)

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

[Robin Tarsiger]

Gregory Heytings wrote:
> Option 1. C-z, with a single exception: "C-z C-z" would be bound to "suspend-frame"
> 
> Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound to "suspend-frame", and "M-z M-z" to
> "zap-to-char"
> 
> Option 3. C-o, with a single exception: "C-o C-o" would be bound to "open-line"
> 
> Option 4. C-o and M-o, with two exceptions: "C-o C-o" would be bound to "open-line", and "M-o M-o" to
> "facemenu-keymap"

In my own init code, I use f8 as a prefix key for a bunch of custom bindings,
including for global Calc, SLIME, and Org commands. This seems similar in general
nature to the desired use for third-party packages, and I notice that f5--f8 are
all available in vanilla Emacs. That would obviously be less disruptive than
repurposing an existing key, but I don't know how reachable those keys are in
everyone's configurations.

For those who use them, M-z and C-o are frequent in normal editing. C-z potentially
less so, but I don't really know that---I would expect it to be more redundant in
GUI Emacs where there is usually a window manager gesture for iconify/deiconify,
but in TTY Emacs it's a necessity; but C-x C-z also exists and indeed parallels
C-x C-c better than C-z currently does. ("Preserve the normal behavior of control
keys" is already out the window from C-c being a prefix, though of course that
doesn't obviate the "users may need to retrain" difficulty with any of these.)

I don't find M-o very useful currently because most modes don't preserve faces
meaningfully, and it's already a prefix key, but that idea feels really weird for
some reason.

I _kind of_ like this general idea because the current situation is getting kind of
hazardous. _But_ if any of these do happen, make sure the symbol for the sub-keymap
is exposed so the user can move the whole thing somewhere else from init code.

-RTT

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

[Stefan Kangas]

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.

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

[Thibaut Verron]

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.

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

[Gregory Heytings]

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

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

[Alan Mackenzie]

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

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

[Augusto Stoffel]

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

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

[Dmitry Gutov]

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.

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

[Lars Ingebrigtsen]

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

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

[Thibaut Verron]

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

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

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

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

[Robin Tarsiger]

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"

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

[Sean Whitton]

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

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

[Ulrich Mueller]

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

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

[Gregory Heytings]

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

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

[Gregory Heytings]

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

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

[Gregory Heytings]

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

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

[Gregory Heytings]

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

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

[Gregory Heytings]

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

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

[Gregory Heytings]

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

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

[Gregory Heytings]

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

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

[Stefan Monnier]

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

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

[Ulrich Mueller]

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

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

[Gregory Heytings]

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

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

[Francis Belliveau]

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

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

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

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

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

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

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


> On Feb 8, 2021, at 05:02, Gregory Heytings <gregory@heytings.org> wrote:
> 
> 
> [S Boucher apparently intended to reply to the following proposal sent on emacs-devel.]
> 
> =Proposal=
> 
> It is proposed to repurpose one key, and to reserve it in the key binding conventions for third-party packages.  The keys that could be reserved for that purpose are:
> 
> Option 1. C-z, with a single exception: "C-z C-z" would be bound to "suspend-frame"
> 
> Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound to "suspend-frame", and "M-z M-z" to "zap-to-char"
> 
> Option 3. C-o, with a single exception: "C-o C-o" would be bound to "open-line"
> 
> Option 4. C-o and M-o, with two exceptions: "C-o C-o" would be bound to "open-line", and "M-o M-o" to "facemenu-keymap"
> 
> =Rationale=
> 
> The current key binding conventions (see `(elisp) Key Binding Conventions') reserve keys for users, for major modes and for minor modes, but not for third-party packages [1].
> 
> When such packages need to bind a command to a key, they can (1) either suggest users to bind it to a key reserved for users (for example, org-mode suggests to globally bind "C-c c" to org-capture), or (2) bind it to a key currently unused by Emacs (for example, Magit binds "C-x g" to magit-status in buffers visiting a file in a Git repository).
> 
> Neither of these solutions are optimal: (1) requires an explicit configuration by the user, something which might confuse newcomers, and which other users might not want to do because they already use the keys reserved for users for other purposes, and (2) might conflict with the evolution of Emacs when one or more commands are bound to a yet unused key.
> 
> Reserving one key for third-party packages solves the above problems: third-party packages can automatically bind a few keys in that reserved area, without conflicting with keys reserved for users and without conflicting with future Emacs evolutions.
> 
> =Limit=
> 
> Conflicts are still possible, when two or more packages bind the same keys.  These are, however, conflicts between packages, not between a package and Emacs, or between a package and users' personal configurations.
> 
> Such conflicts are also less likely for typical users, who install a few packages each binding a few keys.
> 
> Finally, such conflicts can be dealt with without confusing users too much: a package could automatically choose fallback key bindings when the preferred ones are already used by another package, and/or issue a warning to the user that they need to bind its commands manually.
> 
> =Note=
> 
> [1] These conventions were written 25 years ago, at a time when there were far fewer third-party packages, and have not changed substantially since them.
> 

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

[Eric Abrahamsen]

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?

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

[Stefan Kangas]

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.

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

[Stefan Kangas]

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

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

[Stefan Monnier]

> 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

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

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

RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

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

To me, it's far more useful for a repeating
`C-a' (likewise `C-e') to move to the previous
(next) line beginning (end).

Just hold them down to zip along, just like
you do with `C-M-a' (and `C-M-e').  And nearly
every other backward or forward motion command.

In `misc-cmds.el' I define repeatable commands
`beginning-of-line+' and `end-of-line+' that do
that.  (And for my own use I bind them to `C-a'
and `C-e').

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

`M-m' is another that should be repeatable,
doing the same thing on the previous line.

In `misc-cmds.el' I define repeatable command
`back-to-indentation+'.  (Likewise, `forward'.)

(defun back-to-indentation+ ()
  "Move to the first non-whitespace char on this line, or eol if none.
If already there then do the same on the previous line.
This is a repeatable version of `back-to-indentation'."
  (interactive "^")
  (let ((opt  (point)))
    (back-to-indentation)
    (when (= opt (point))
      (forward-line -1)
      (back-to-indentation))))

(If someone uses both backward and forward,
`M-p' and `M-n' make more sense than `M-m'.)
___


https://www.emacswiki.org/emacs/download/misc-cmds.el

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

[Richard Stallman]

[[[ 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)

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

[Jean Louis]

* 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

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

[Yuri Khan]

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.

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

[Marcin Borkowski]

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

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

[Lars Ingebrigtsen]

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

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

[Gregory Heytings]

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

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

[Gregory Heytings]

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

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

[Gregory Heytings]

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

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

[Simen Heggestøyl]

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

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

[Gregory Heytings]

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

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

[Juri Linkov]

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

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

[Gregory Heytings]

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

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

[Sean Whitton]

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

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

[Sean Whitton]

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

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

[Sean Whitton]

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

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

[Lars Ingebrigtsen]

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

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

[Gregory Heytings]

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

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

[Eli Zaretskii]

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

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

[Ulrich Mueller]

>>>>> 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?)

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

[Thibaut Verron]

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

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

[Gregory Heytings]

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

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

[Stefan Monnier]

> 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

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

[Gregory Heytings]

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

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

[Gregory Heytings]

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

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

[Thibaut Verron]

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?

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

[Stefan Monnier]

> 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

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

[Gregory Heytings]

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

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

[Gregory Heytings]

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

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

[Sean Whitton]

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

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

[Sean Whitton]

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

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

[Gregory Heytings]

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

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

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 4298 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>> 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.
>>
>> I don't think this is a good idea, because situation (1) is good,
>> actually.  Configuring a package, that provides a command as it's 
>> interface, should be done by binding it to a key reserved for
>> users. Just like how configuring a minor mode is done by adding it
>> to a hook or a major mode by adding it to auto-mode-alist.
>>
>
> Situation (1) might be good in theory, it was probably good twenty
> years ago, but at least nowadays it is, in practice, not good.  What
> most users do is that they install third-party packages through their
> distro package manager, or through Elpa or Melpa, and they just expect
> / would like it to work.  That's what would happen when you install
> extension packages in most (if not all) other software (editors,
> browsers, ...): you don't have to manually fiddle with configuration
> files to make them work.

If I install ffmpeg via apt on a Debian system, I expect it to work, in
the sense that I can invoke the command from the terminal whenever I
want to use it.  I don't think the analogy works for browsers, since
add-ons are usually filters or added to right-click menus.  I don't know
enough about other extensible editors, but if they do too-smart-for-me
guessing, that's probably why I don't use them.

What might be interesting would be something like the gnu-elpa
package[0], or something that goes in the other direction, where a
package can recommend a keybinding, hook, etc. and "automatically"
configure itself if the user agrees.

The problem I see is that key-bindings are usually user configuration,
and e.g. Magit *works* without them. I can do M-x magit-status, right
after installing it. No extra configuration necessary. But if I want to
have it easier, it's easy to add.

> It's probably not without reasons that packages such as Magit bind
> keys globally.

AFAIK this was discussed in [1], but I don't get it, and I think it was
a bad decision.

>>
>> If you ask me, packages should try to minimize change the
>> environment when they are installed, as I've argued in [0].  In
>> other words, package-install shouldn't have any side-effects, beyond
>> installing a package.
>>
>
> That's not what most users expect.  When you install a package, you
> just expect it to work.  If they install a package to edit, say,
> Python code, they expect it will be used the next time they open a .py
> file.  If they install Magit, they expect it will work when they open
> a file in a git repository.  If they install Ivy, they expect it will
> take over C-x C-f, C-x b, and so forth.

I think Ivy is a good example where this should *not* be the case,
because it changes the user-interface that can be confusing. Major modes
might be ok, but the edge-cases is where it's critical: Let's say there
were two third-party packages for perl and prolog. It's common for both
to use the ".pl" extension, but which should get it. If I have been
using perl for a while, and I install prolog, should the new package
just "steal" the extension? Same goes for key-bindings. This should not
be done automatically, and reserving a name-space to solve this issue is
the wrong approach.

But setting that aside, I think that this expectation is just "wrong".
Packaging doesn't do configuration, and we shouldn't encourage this
misunderstanding. What works for some, breaks stuff for other people,
and that should be respected.

[0] http://elpa.gnu.org/packages/gnu-elpa.html
[1] https://github.com/magit/magit/pull/4237

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

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

[Richard Stallman]

[[[ 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)

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

[Robert Thorpe]

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

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

[Thibaut Verron]

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.

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

[Alfred M. Szmidt]

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?

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

[Gregory Heytings]

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

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

[Gregory Heytings]

>>> Configuring a package, that provides a command as it's interface, 
>>> should be done by binding it to a key reserved for users. Just like 
>>> how configuring a minor mode is done by adding it to a hook or a major 
>>> mode by adding it to auto-mode-alist.
>>
>> What most users do is that they install third-party packages through 
>> their distro package manager, or through Elpa or Melpa, and they just 
>> expect / would like it to work.  That's what would happen when you 
>> install extension packages in most (if not all) other software 
>> (editors, browsers, ...): you don't have to manually fiddle with 
>> configuration files to make them work.
>
> If I install ffmpeg via apt on a Debian system, I expect it to work, in 
> the sense that I can invoke the command from the terminal whenever I 
> want to use it.  I don't think the analogy works for browsers, since 
> add-ons are usually filters or added to right-click menus.
>

The point is that those "filters" or "right-click menus" are activated, 
you can use them right away, you don't have to manually edit, say, the 
~/.config/chromium/init.js file beforehand.  If you had to do that, you 
would likely think it's a badly designed browser.  All Emacs users are not 
programmers like you and me.

>
> What might be interesting would be something like the gnu-elpa 
> package[0], or something that goes in the other direction, where a 
> package can recommend a keybinding, hook, etc. and "automatically" 
> configure itself if the user agrees.
>

If there is no keymap reserved for package keybindings, packages simply 
cannot do that.  The point of the proposal is only to make that possible.

>
> The problem I see is that key-bindings are usually user configuration, 
> and e.g. Magit *works* without them. I can do M-x magit-status, right 
> after installing it. No extra configuration necessary. But if I want to 
> have it easier, it's easy to add.
>

For you and me, yes.  For Emacs users in general, no.

>
> I think Ivy is a good example where this should *not* be the case, 
> because it changes the user-interface that can be confusing.
>

When you install a package whose purpose is to change the user interface, 
you expect it will change the user interface, don't you?  When you install 
an ad-blocker in your browser, you expect it will block ads, don't you?

>
> Packaging doesn't do configuration, and we shouldn't encourage this 
> misunderstanding.
>

Some users, like you and me, don't want Emacs packages to automatically 
configure themselves, that's fine and will always be possible.  Other 
users, like me when I install a GIMP plugin, want that GIMP plugin to be 
automatically configured.  I would be very confused if I had to manually 
edit the ~/.config/GIMP/X.YZ/gimprc and/or ~/.config/GIMP/X.YZ/pluginrc 
before using a plugin.

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

[Gregory Heytings]

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

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

[Jean Louis]

* 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

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

[Thibaut Verron]

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

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

[Alfred M. Szmidt]

   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. 

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

[Alfred M. Szmidt]

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

vc-magit mode (was: Re: PROPOSAL: Repurpose one key and reserve it for third-party packages)

[Alfred M. Szmidt]

Here is an idea, a new backend -- vc-magit.  This calls the right
Magit functions.  The user can then set the prefered backends using
vc-handled-backends.  This solves the (specific) conundrum of taking
e.g., C-x g, and also provides the user with a consitent interface to
VC mode when using magit.

When in a buffer that has a git repository associated and your backend
is vc-magit, vc-prefix-map, can be used by vc-magit / magit to bind
specific magit keybindings that are not VC agonstic.

Re: vc-magit mode (was: Re: PROPOSAL: Repurpose one key and reserve it for third-party packages)

[Thibaut Verron]

Le mer. 10 févr. 2021 à 14:09, Alfred M. Szmidt <ams@gnu.org> a écrit :
>
> Here is an idea, a new backend -- vc-magit.  This calls the right
> Magit functions.  The user can then set the prefered backends using
> vc-handled-backends.  This solves the (specific) conundrum of taking
> e.g., C-x g, and also provides the user with a consitent interface to
> VC mode when using magit.
>
> When in a buffer that has a git repository associated and your backend
> is vc-magit, vc-prefix-map, can be used by vc-magit / magit to bind
> specific magit keybindings that are not VC agonstic.
>

Would it be technically possible to have C-x v behave as a prefix for
vc-mode and spawn a buffer with its own minor mode for vc-magit?

Re: vc-magit mode

[Dmitry Gutov]

On 10.02.2021 15:09, Alfred M. Szmidt wrote:
> Here is an idea, a new backend -- vc-magit.  This calls the right
> Magit functions.  The user can then set the prefered backends using
> vc-handled-backends.  This solves the (specific) conundrum of taking
> e.g., C-x g, and also provides the user with a consitent interface to
> VC mode when using magit.

You've never used Magit, have you?

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

[Gregory Heytings]

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

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

[Alfred M. Szmidt]

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

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

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

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

[Gregory Heytings]

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

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

[Gregory Heytings]

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

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

[Alfred M. Szmidt]

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

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

[Gregory Heytings]

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

Re: vc-magit mode (was: Re: PROPOSAL: Repurpose one key and reserve it for third-party packages)

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Date: Wed, 10 Feb 2021 08:09:45 -0500
> Cc: eric@ericabrahamsen.net, spwhitton@spwhitton.name, rms@gnu.org,
>  emacs-devel@gnu.org
> 
> Here is an idea, a new backend -- vc-magit.  This calls the right
> Magit functions.  The user can then set the prefered backends using
> vc-handled-backends.

Dmitry will tell for sure, but I think adapting Magit to the VC
architecture won't be easy, since Magit is not exactly a backend like
the other ones.  The VC framework might be a kind of Procrustean bed
for Magit.

RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

> org-mode specific bindings don't make sense
> outside of org-mode and mode specific keybindings
> already have a set that is already reserved for them.

See bug #46087 (which has so far had no response).

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46087

> The issue as I understood it was that there are
> some modes that have bindings that make sense
> in a global context.

Yes, that is indeed one of the points.

RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

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

Org-mode also binds keys (at least one) globally
that (AFAIK) cannot possibly have a use outside
of an org-mode buffer.

Bug #46087:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46087

Re: vc-magit mode (was: Re: PROPOSAL: Repurpose one key and reserve it for third-party packages)

[Alfred M. Szmidt]

   > Here is an idea, a new backend -- vc-magit.  This calls the right
   > Magit functions.  The user can then set the prefered backends using
   > vc-handled-backends.

   Dmitry will tell for sure, but I think adapting Magit to the VC
   architecture won't be easy, since Magit is not exactly a backend like
   the other ones.  The VC framework might be a kind of Procrustean bed
   for Magit.

Even if the architecture makes it complciated to do it using a vc
backend, magit could still take over the C-x v binding for its own
purpose with similar semantics to what is in vc-mode.  It wouldn't
need to be entierly compatible -- but C-x v v could still work as
"commit this file", etc.

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

[Stefan Monnier]

>> The issue as I understood it was that there are
>> some modes that have bindings that make sense
>> in a global context.
>
> Yes, that is indeed one of the points.

A related example is GUD's command to set a break point.


        Stefan

Re: vc-magit mode (was: Re: PROPOSAL: Repurpose one key and reserve it for third-party packages)

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Cc: thibaut.verron@gmail.com, eric@ericabrahamsen.net,
> 	spwhitton@spwhitton.name, rms@gnu.org, emacs-devel@gnu.org
> Date: Wed, 10 Feb 2021 11:47:05 -0500
> 
>    > Here is an idea, a new backend -- vc-magit.  This calls the right
>    > Magit functions.  The user can then set the prefered backends using
>    > vc-handled-backends.
> 
>    Dmitry will tell for sure, but I think adapting Magit to the VC
>    architecture won't be easy, since Magit is not exactly a backend like
>    the other ones.  The VC framework might be a kind of Procrustean bed
>    for Magit.
> 
> Even if the architecture makes it complciated to do it using a vc
> backend, magit could still take over the C-x v binding for its own
> purpose with similar semantics to what is in vc-mode.

I said nothing about keybindings, only about your suggestion to make
Magit another VC backend.

Bindings for setting faces (was: PROPOSAL: Repurpose one key and reserve it for third-party packages)

[Kévin Le Gouguec]

Sean Whitton <spwhitton@spwhitton.name> writes:

> For the sake of ease of use I'd suggest replacing M-o b with C-c C-c b.

FWIW (inspiration? avoiding conflicts? 🤷), here's a non-exhaustive
survey of some bindings from major modes derived from text-mode, some of
which propose a WYSIWYG-ish experience:

- AUCTeX: C-c C-f C-[X]
  examples of [X]:
  b → \textbf{bold}
  e → \emph{emphasized}
  i → \textit{italic}

- org-mode: C-c C-x C-f [X]
  examples of [X]:
  * → *bold*
  / → /italic/
  _ → _underlined_
  = → =verbatim=

- markdown-mode: C-c C-s [X]
  examples of [X]:
  b → **bold**
  e → *emphasized*
  q → > quote
  c → `code`
  1 → # Title 1
  2 → ## Title 2

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

[Francis Belliveau]

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

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

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 4455 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>>> Configuring a package, that provides a command as it's interface,
>>>> should be done by binding it to a key reserved for users. Just
>>>> like how configuring a minor mode is done by adding it to a hook
>>>> or a major mode by adding it to auto-mode-alist.
>>>
>>> What most users do is that they install third-party packages
>>> through their distro package manager, or through Elpa or Melpa, and
>>> they just expect / would like it to work.  That's what would happen
>>> when you install extension packages in most (if not all) other
>>> software (editors, browsers, ...): you don't have to manually
>>> fiddle with configuration files to make them work.
>>
>> If I install ffmpeg via apt on a Debian system, I expect it to work,
>> in the sense that I can invoke the command from the terminal
>> whenever I want to use it.  I don't think the analogy works for
>> browsers, since add-ons are usually filters or added to right-click
>> menus.
>>
>
> The point is that those "filters" or "right-click menus" are
> activated, you can use them right away, you don't have to manually
> edit, say, the ~/.config/chromium/init.js file beforehand.  If you had
> to do that, you would likely think it's a badly designed browser.

My point is that it makes sense for browsers, because the plug-in
framework has its boundaries, so "activation by default" is safe.

> All Emacs users are not programmers like you and me.

So what? Emacs is still the programmable text editor. I personally think
it is a great mistake that the default UX wants to hide computability,
and the fact that Emacs doesn't do that, is good. Free Software, on some
level is just about blurring the line between programmer (producer) and
user (consumer).

>> What might be interesting would be something like the gnu-elpa
>> package[0], or something that goes in the other direction, where a 
>> package can recommend a keybinding, hook, etc. and "automatically"
>> configure itself if the user agrees.
>>
>
> If there is no keymap reserved for package keybindings, packages
> simply cannot do that.  The point of the proposal is only to make that
> possible.

Why? Let's say a package includes a like like

        ;;;###autoload
        (add-to-list 'package-configuration-advertisement
                     '(avy (key "C-c z") avy-goto-word-1))

and package-install, when called interactively, checks if the key "C-c
z" has been bound, if the user is interested in what packages suggest,
etc.  and then suggests adding this keybinding. You can answer with
"yes", "no" or "other key", and it will automatically add it to your
init.el. No designated keyspace needed.

>> The problem I see is that key-bindings are usually user
>> configuration, and e.g. Magit *works* without them. I can do M-x
>> magit-status, right after installing it. No extra configuration
>> necessary. But if I want to have it easier, it's easy to add.
>>
>
> For you and me, yes.  For Emacs users in general, no.

How come? I don't know what you are referring to.

>> I think Ivy is a good example where this should *not* be the case,
>> because it changes the user-interface that can be confusing.
>>
>
> When you install a package whose purpose is to change the user
> interface, you expect it will change the user interface, don't you?
> When you install an ad-blocker in your browser, you expect it will
> block ads, don't you?

Again, the browser is a different situation. When I install a package, I
expect the package to be installed, that's it. I don't know if I want to
keep the package, I don't know how I want to use the package or
sometimes what it does. This kind of aggressive behaviour just makes
harder because you don't know what is going on. This is how you confuse
newcomers.

>> Packaging doesn't do configuration, and we shouldn't encourage this
>> misunderstanding.
>
> Some users, like you and me, don't want Emacs packages to
> automatically configure themselves, that's fine and will always be
> possible.  Other users, like me when I install a GIMP plugin, want
> that GIMP plugin to be automatically configured.  I would be very
> confused if I had to manually edit the ~/.config/GIMP/X.YZ/gimprc
> and/or ~/.config/GIMP/X.YZ/pluginrc before using a plugin.

Again, packages != plug-ins. We shouldn't dumb-down Emacs.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

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

[Gregory Heytings]

[Why did you write your first mail off-list, your second one Cc'd to 
emacs-devel, and your third one Cc'd to help-gnu-emacs?]

>> When you install a package whose purpose is to change the user 
>> interface, you expect it will change the user interface, don't you? 
>> When you install an ad-blocker in your browser, you expect it will 
>> block ads, don't you?
>
> Again, the browser is a different situation.
>

For most users, it is not.  I guess you think the browser or GIMP are 
different situations, because you see them as mere tools, whereas you see 
Emacs as "more than a tool".  That's not the case for most Emacs users, 
for them Emacs is just a tool.  FWIW, when I open another editor, I see 
and use it as a mere tool for another task.

>
> This kind of aggressive behaviour just makes harder because you don't 
> know what is going on. This is how you confuse newcomers.
>

Regular users don't want to know what is going on, they don't care, and 
shouldn't have to care; for them an editor is just a tool for another 
task.

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

[Arthur Miller]

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

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

[Richard Stallman]

[[[ 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)

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

[Richard Stallman]

[[[ 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)

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

[Richard Stallman]

[[[ 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)

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

[Thibaut Verron]

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.

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

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

> [Why did you write your first mail off-list, your second one Cc'd to
> emacs-devel, and your third one Cc'd to help-gnu-emacs?]

Sorry about that, forgot to Cc in the first message, and then I resent
the message to the wrong list.

>>> When you install a package whose purpose is to change the user
>>> interface, you expect it will change the user interface, don't you? 
>>> When you install an ad-blocker in your browser, you expect it will
>>> block ads, don't you?
>>
>> Again, the browser is a different situation.
>
> For most users, it is not.  I guess you think the browser or GIMP are
> different situations, because you see them as mere tools, whereas you
> see Emacs as "more than a tool".  That's not the case for most Emacs
> users, for them Emacs is just a tool.  FWIW, when I open another
> editor, I see and use it as a mere tool for another task.

No, the difference is that Emacs is a interactive computing environment
while GIMP and browsers are programs with extension models. But that's
not my main point:

All in all, I don't have a problem with Emacs being able to support it,
but as I've shown with the example in my last message, it doesn't need
to be done automatically, nor does it require a separate key. It's
ultimately up to the user what he or she wants to do, and clever
behind-your-back customization seems more harmful and confusing than the
current state of affairs.

>> This kind of aggressive behaviour just makes harder because you
>> don't know what is going on. This is how you confuse newcomers.
>
> Regular users don't want to know what is going on, they don't care,
> and shouldn't have to care; for them an editor is just a tool for
> another task.

I don't like the notion of a "regular user", but in principle I
agree. The open question is what this means. I don't think users should
be obstructed and confused, and I fear that what you propose has the
danger to do just that.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

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

[Gregory Heytings]

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

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

[Stefan Kangas]

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.

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

[Robert Pluim]

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

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

[Philip K.]

[-- Attachment #1.1: Type: text/plain, Size: 500 bytes --]

"Philip K." <philipk@posteo.net> writes:

> All in all, I don't have a problem with Emacs being able to support it,
> but as I've shown with the example in my last message, it doesn't need
> to be done automatically, nor does it require a separate key. It's
> ultimately up to the user what he or she wants to do, and clever
> behind-your-back customization seems more harmful and confusing than the
> current state of affairs.

Just for the sake of it, this is a draft of how this could look like:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-Add-package-suggest-configuration.patch --]
[-- Type: text/x-patch, Size: 6146 bytes --]

From 3e78e4e61462f116a56224e0750401e9b9596e1f Mon Sep 17 00:00:00 2001
From: Philip K <philipk@posteo.net>
Date: Thu, 11 Feb 2021 16:30:09 +0100
Subject: [PATCH] Add package-suggest-configuration

---
 lisp/emacs-lisp/package.el | 99 ++++++++++++++++++++++++++++++++------
 1 file changed, 85 insertions(+), 14 deletions(-)

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 90b7b88d58..6ddd363003 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -145,6 +145,7 @@
 
 (require 'cl-lib)
 (eval-when-compile (require 'subr-x))
+(eval-when-compile (require 'pcase))
 (eval-when-compile (require 'epg))      ;For setf accessors.
 (require 'seq)
 
@@ -2087,6 +2088,88 @@ package--archives-initialize
   (unless package-archive-contents
     (package-refresh-contents)))
 
+(defcustom package-ignore-suggestions nil
+  "Should package-"
+  :type '(choice (const :tag "Ask the user" nil)
+                 (const :tag "Never ask" t)
+                 (set :tag "Ignore certain suggestions"
+                      (const :tag "Keybindings" key)
+                      (const :tag "User Options" option)
+                      (const :tag "Hooks" hook)))
+  :version "28.1")
+
+(defvar pacakge-configuration-suggestions nil
+  "An alist of advertised default configuration.
+Each entry has the form (PACKAGE . SUGGESTIONS), where PACAKGE is
+a symbol designating the package, and SUGGESTIONS is another
+alist.  SUGGESTIONS have the form (TYPE . DATA), where TYPE says
+what kind of a suggestion is being made and DATA is the content
+of the suggestion.  Currently, the following values for TYPE are
+understood:
+
+- `key', where DATA has the form (KEY FUNCTION).  It suggests
+  binding FUNCTION globally to KEY, unless KEY is already bound.
+  KEY is passed to the function `kbd'.
+
+- `option', where DATA has the form (OPT VAL).  It setting the
+  symbol OPT to the value VAL.
+
+- `hook', where DATA has the form (HOOK FUNCTION).  It suggests
+  adding FUNCTION to the hook HOOK.
+
+All other values for TYPE are ignored.")
+
+(defun package--query-name (&optional kind verb)
+  "Query the user for a package name.
+If KIND is nil, prompt for all kinds of packages.  If KIND is
+`installed' only prompt for installed packages.  If KIND is
+`not-installed', only prompt for packages that have not been
+installed.  VERB modified to prompt."
+  ;; Initialize the package system to get the list of package
+  ;; symbols for completion.
+  (package--archives-initialize)
+  (intern (completing-read
+           (format "%s package: " (or verb "Select"))
+           (delq nil (mapcar (lambda (elt)
+                               (when (cond
+                                      ((eq kind 'installed)
+                                       (package-installed-p (car elt)))
+                                      ((eq kind 'not-installed)
+                                       (not (package-installed-p (car elt))))
+                                      ((null kind))
+                                      (t (error "Invalid kind")))
+                                 (symbol-name (car elt))))
+                             package-archive-contents))
+           nil t)))
+
+(defun package-suggest-configuration (package &optional dont-load)
+  "Query the user to automatically configure PACKAGE.
+If DONT-LOAD is non-nil, do not load the new customization."
+  (interactive (list (package--query-name 'installed) current-prefix-arg))
+  (unless (and (not (called-interactively-p 'any))
+               (eq package-ignore-suggestions t))
+    (let ((temp-buffer-show-function #'ignore)
+          (save-silently t))
+      (with-temp-buffer
+        (with-output-to-temp-buffer (current-buffer)
+          (dolist (sug (cdr (assq package pacakge-configuration-suggestions)))
+            (unless (memq (car sug) package-ignore-suggestions)
+              (terpri nil t)
+              (pcase sug
+                (`(key ,key ,fn)
+                 (when (yes-or-no-p (format "Bind %s to \"%s\"?" fn key))
+                   (prin1 `(global-set-key (kbd ,key) #',fn))))
+                (`(option ,opt ,val)
+                 (when (yes-or-no-p (format "Set option %s to %S?" opt val))
+                   (prin1 `(customize-set-variable ',opt ,val))))
+                (`(hook ,hook ,fn)
+                 (when (yes-or-no-p (format "Add %s to hook %S?" fn hook))
+                   (prin1 `(add-hook ',hook #',fn)))))))
+          (unless dont-load
+            (eval-buffer))
+          (append-to-file (point-min) (point-max)
+                          (or custom-file user-init-file)))))))
+
 ;;;###autoload
 (defun package-install (pkg &optional dont-select)
   "Install the package PKG.
@@ -2103,20 +2186,7 @@ package-install
 
 If PKG is a `package-desc' and it is already installed, don't try
 to install it but still mark it as selected."
-  (interactive
-   (progn
-     ;; Initialize the package system to get the list of package
-     ;; symbols for completion.
-     (package--archives-initialize)
-     (list (intern (completing-read
-                    "Install package: "
-                    (delq nil
-                          (mapcar (lambda (elt)
-                                    (unless (package-installed-p (car elt))
-                                      (symbol-name (car elt))))
-                                  package-archive-contents))
-                    nil t))
-           nil)))
+  (interactive (list (package--query-name 'not-installed "Install")))
   (package--archives-initialize)
   (add-hook 'post-command-hook #'package-menu--post-refresh)
   (let ((name (if (package-desc-p pkg)
@@ -2134,6 +2204,7 @@ package-install
         (progn
           (package-download-transaction transaction)
           (package--quickstart-maybe-refresh)
+          (package-suggest-configuration pkg)
           (message  "Package `%s' installed." name))
       (message "`%s' is already installed" name))))
 
-- 
2.29.2


[-- Attachment #1.3: Type: text/plain, Size: 19 bytes --]


-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

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

[Gregory Heytings]

>
> the difference is that Emacs is a interactive computing environment 
> while GIMP and browsers are programs with extension models.
>

I'm not sure I understand the difference, and for most users Emacs is not 
an "interactive computing environment", it's a text editor, like Atom, 
Visual Studio, or Vim.

>
> All in all, I don't have a problem with Emacs being able to support it, 
> but as I've shown with the example in my last message, it doesn't need 
> to be done automatically, nor does it require a separate key.
>

The problem of what you propose is that, even if it were possible (AFAIU 
it isn't, given Emacs' key binding conventions), it would be a very 
limited solution: there are only 26 keys reserved for users.  Okay, 52, if 
you count capital letters.

>
> It's ultimately up to the user what he or she wants to do, and clever 
> behind-your-back customization seems more harmful and confusing than the 
> current state of affairs.
>

It's what most users expect.  apt install elpa-magit, C-x g, and voilà: 
Magit works.  BTW, Emacs already does "behind-your-back" customizations, 
and doesn't ask you any questions for them.  It provides sensible 
defaults, which work in most cases, and which you can change if need be.

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

[Stefan Monnier]

> 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

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

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>> the difference is that Emacs is a interactive computing environment
>> while GIMP and browsers are programs with extension models.
>
> I'm not sure I understand the difference, and for most users Emacs is
> not an "interactive computing environment", it's a text editor, like
> Atom, Visual Studio, or Vim.

Just because it appears to be something at first glance, doesn't mean it
should behave/limit itself to this misapprehension.

>> All in all, I don't have a problem with Emacs being able to support
>> it, but as I've shown with the example in my last message, it
>> doesn't need to be done automatically, nor does it require a
>> separate key.
>>
>
> The problem of what you propose is that, even if it were possible
> (AFAIU it isn't, given Emacs' key binding conventions), it would be a
> very limited solution: there are only 26 keys reserved for users.
> Okay, 52, if you count capital letters.

Wait, if a key were designated, you would have the same issue? But even
then, you can bind a key to a sub-map, you can rebind exiting keys if a
package improves on an existing key and you could suggest more than one
key.

>> It's ultimately up to the user what he or she wants to do, and
>> clever behind-your-back customization seems more harmful and
>> confusing than the current state of affairs.
>
> It's what most users expect.  apt install elpa-magit, C-x g, and
> voilà: Magit works. 

How do you come to this conclusion? And why does it matter if it is a
"wrong" expectation?

> BTW, Emacs already does "behind-your-back" customizations, and doesn't
> ask you any questions for them.  It provides sensible defaults, which
> work in most cases, and which you can change if need be.

I don't get your point here. Are you saying "default Emacs" is a
"behind-your-back customization"?

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

> Regular users don't want to know what is going on,
> they don't care, and shouldn't have to care; for
> them an editor is just a tool for another task.

Apologies for chiming in here without having
read the context, and for responding to this
out of context.

I would say that such "regular users" aren't
what Emacs is about, and that regular (i.e.,
ordinary) Emacs users are, quite a bit,
interested in what is going on, to varying
degrees.  And with increasing degree as Emacs
becomes more a part of them.

Emacs, especially because of (1) Emacs Lisp
and (2) free software (source code, user
participation in development), blurs, and
can erase, the boundary between ordinary user
and hard-core Emacs developer.

Yes, for many Emacs users "an editor is just
a tool for another task" perhaps.  But for
many Emacs users - and "Emacs user" in its
real potential, that use-for-other-tasks is
not separate from knowing what's going on.

IOW, the "regular editor user" stereotype
doesn't really fit "Emacs user", even if
many Emacs users might start out looking
at Emacs as a regular editor and acting,
themselves, as regular users.

RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

> > the difference is that Emacs is a interactive computing environment
> > while GIMP and browsers are programs with extension models.
> 
> I'm not sure I understand the difference, and for
> most users Emacs is not an "interactive computing
> environment", it's a text editor, like Atom,
> Visual Studio, or Vim.

When speaking for, or about, "most users" of Emacs,
it would help to show some justification.

If you mean only that this is your personal
sense/impression/idea about what most Emacs users
think or how they act, then it's fine as is (but
it's better to explicitly say that).

More importantly:  Even if what you say were true,
that doesn't mean that that's what Emacs is _for_.

Emacs, like everything else, is really _for_
whatever you can do with it - whatever you can use
it for in a handy way.  And in the case of Emacs
that's a _lot_ more than what the typical text
editor offers.

We started with a Lisp-based text editor with freely
available source code, and we ended up with, well,
a super-powerful black hole. ;-)

Any description of Emacs includes features such as
extensibility, introspection, access to all source
code, etc.  It's really not a "regular" text editor,
and from that _it follows_ that its users are not
regular editor users (regardless of how many might
take advantage of the features that make it special,
and regardless of how deeply they take advantage of
those features).

> > It's ultimately up to the user what he or she
> > wants to do, and clever behind-your-back
> > customization seems more harmful and confusing
> > than the current state of affairs.
> 
> It's what most users expect.

See above.  Talk of "what most users expect" cries
out for (1) justification (how do you know?) and
(2) relevance (how important is what most expect
at the outset, if you're talking about new users?)

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

[Leo Butler]

Gregory Heytings <gregory@heytings.org> writes:

>>> When you install a package whose purpose is to change the user
>>> interface, you expect it will change the user interface, don't you? 
>>> When you install an ad-blocker in your browser, you expect it will
>>> block ads, don't you?
>>
>> Again, the browser is a different situation.
>>
>
> For most users, it is not.  I guess you think the browser or GIMP are
> different situations, because you see them as mere tools, whereas you
> see Emacs as "more than a tool".  That's not the case for most Emacs
> users, for them Emacs is just a tool.  FWIW, when I open another
> editor, I see and use it as a mere tool for another task.

I agree with what Philip K. has written.

>
>>
>> This kind of aggressive behaviour just makes harder because you
>> don't know what is going on. This is how you confuse newcomers.

Agreed.

>>
>
> Regular users don't want to know what is going on, they don't care,
> and shouldn't have to care; for them an editor is just a tool for
> another task.

Sometimes, one really must understand what is going on.

I have found, through bitter experience, that expecting a piece of
software to 'just work' is a fool's paradise. My favourite example is a
bug I encountered in open/libreoffice where non-ascii digit characters
copied into a spreadsheet are simply treated as strings (and silently
coerced to 0 when doing arithmetic). I could go on a rant about how a
succession of developers have refused to fix the bug, how hard
libreoffice made it to even identify the bug, or how easy it would be to
fix it, but suffice it to say that 10 years later, the bug is still not
fixed and I use emacs.

Leo

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

[Gregory Heytings]

>> The problem of what you propose is that, even if it were possible 
>> (AFAIU it isn't, given Emacs' key binding conventions), it would be a 
>> very limited solution: there are only 26 keys reserved for users. Okay, 
>> 52, if you count capital letters.
>
> Wait, if a key were designated, you would have the same issue? But even 
> then, you can bind a key to a sub-map, you can rebind exiting keys if a 
> package improves on an existing key and you could suggest more than one 
> key.
>

No, with one control key you have all characters (not just letters, also 
digits and symbols), plus all C-something, plus all M-something, plus 
C-M-something.  With one control key and its corrsponding meta key you 
multiply that number by two.

>> It's what most users expect.  apt install elpa-magit, C-x g, and voilà: 
>> Magit works.
>
> How do you come to this conclusion?
>

It's what Magit (and other similar packages) do.  The presupposition of 
the proposal is that such packages know their users.

>> BTW, Emacs already does "behind-your-back" customizations, and doesn't 
>> ask you any questions for them.  It provides sensible defaults, which 
>> work in most cases, and which you can change if need be.
>
> I don't get your point here. Are you saying "default Emacs" is a 
> "behind-your-back customization"?
>

No, I mean that installing packages already does some "behind-your-back" 
customizations, for example by modifying auto-mode-alist.  There are cases 
when such modifications do not what some particular user would expect; as 
someone mentioned, a package for Perl who would override the setting of a 
package for Prolog because both use the .pl extension.

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

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 2882 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

> No, with one control key you have all characters (not just letters,
> also digits and symbols), plus all C-something, plus all M-something,
> plus C-M-something.  With one control key and its corrsponding meta
> key you multiply that number by two.

Ah ok, I get what you mean. Does it really make that much of a
difference? I'm not sure how many packages you are expecting would add
default bindings (or how conflict resolution should happen), but do you
really need more than 26? How many packages do people install, where an
interactive command is the entry-point _and_ has to be bound to a key by
default? In my case it is only Magit, and that's bound to C-c g without
any problems.

Also, here's another annoyance: What if I don't like the default
binding? How would you expect this to be modified? Would a package
constantly try to modify my config to add what it thinks should be the
right key to trigger the right command?

>>> It's what most users expect.  apt install elpa-magit, C-x g, and
>>> voilà: Magit works.
>>
>> How do you come to this conclusion?
>
> It's what Magit (and other similar packages) do.  The presupposition
> of the proposal is that such packages know their users.

I only know of Magit that does it, and as I have said before, I think it
is a mistake and unfriendly. But that still doesn't answer the
question. Why do you think that users expect it -- not the image that
magit has it it's users.

>>> BTW, Emacs already does "behind-your-back" customizations, and
>>> doesn't ask you any questions for them.  It provides sensible
>>> defaults, which work in most cases, and which you can change if
>>> need be.
>>
>> I don't get your point here. Are you saying "default Emacs" is a
>> "behind-your-back customization"?
>
> No, I mean that installing packages already does some
> "behind-your-back" customizations, for example by modifying
> auto-mode-alist.  There are cases when such modifications do not what
> some particular user would expect; as someone mentioned, a package for
> Perl who would override the setting of a package for Prolog because
> both use the .pl extension.

Yes, and as I have said in a previous message (or in my article for that
matter), I think it is problematic. Lucky the situation with
auto-mode-alist is more relaxed, since auto-mode-list benefits from the
fact that file extensions tend not to conflict with one-another
(survival of the more popular).

Also, if I am not mistaken, packages that manipulate auto-mode-alist add
their entry to the end of the list, so that if a user wants to interpret
.pl as whatever they want, they won't interfere. This kind of a respect
for the user would have to be necessary for what you propose, so that an
implicit Emacs etiquette is preserved.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

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

[Gregory Heytings]

>> No, with one control key you have all characters (not just letters, 
>> also digits and symbols), plus all C-something, plus all M-something, 
>> plus C-M-something.  With one control key and its corrsponding meta key 
>> you multiply that number by two.
>
> Ah ok, I get what you mean. Does it really make that much of a 
> difference? I'm not sure how many packages you are expecting would add 
> default bindings (or how conflict resolution should happen), but do you 
> really need more than 26?
>

That reminds me the famous "640 kb should be enough for anyone" ;-) 
Indeed, 26 letters is not enough.  Magit has three global commands, 
Org-mode has three, and Bookmark+ has three keymaps.  With just three 
packages you've already used 35% of the available keys.  I hope you 
understand that it can't be a long-term solution.  Moreover, AFAIU, 
packages cannot automatically bind their commands to C-c LETTER keys 
anyway: these keys are strictly reserved for users in their personal 
configuration files.

>>>> It's what most users expect.  apt install elpa-magit, C-x g, and 
>>>> voilà: Magit works.
>>>
>>> How do you come to this conclusion?
>>
>> It's what Magit (and other similar packages) do.  The presupposition of 
>> the proposal is that such packages know their users.
>
> I only know of Magit that does it, and as I have said before, I think it 
> is a mistake and unfriendly. But that still doesn't answer the question. 
> Why do you think that users expect it -- not the image that magit has it 
> it's users.
>

Being a programmer, I can understand your viewpoint.  As a user I can't. 
With M-x load-theme <something>, the user interface changes.  What makes 
keybindings so different from user interface colors that they should 
absolutely not be touched when a package is loaded, say with M-x 
global-foobar-mode, and require an explicit manual configuration by the 
user?  Do you also think it's a mistake and unfriendly if a package 
installs a menu item?  If not, what makes keybindings fundamentally 
different from menu items?

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

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 3309 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>> No, with one control key you have all characters (not just letters,
>>> also digits and symbols), plus all C-something, plus all
>>> M-something, plus C-M-something.  With one control key and its
>>> corrsponding meta key you multiply that number by two.
>>
>> Ah ok, I get what you mean. Does it really make that much of a
>> difference? I'm not sure how many packages you are expecting would
>> add default bindings (or how conflict resolution should happen), but
>> do you really need more than 26?
>>
>
> That reminds me the famous "640 kb should be enough for anyone" ;-)
> Indeed, 26 letters is not enough.  Magit has three global commands, 
> Org-mode has three, and Bookmark+ has three keymaps.  With just three
> packages you've already used 35% of the available keys.  I hope you 
> understand that it can't be a long-term solution.  Moreover, AFAIU,
> packages cannot automatically bind their commands to C-c LETTER keys 
> anyway: these keys are strictly reserved for users in their personal
> configuration files.

I think that's the pessimistic way to look at it, the optimistic one
would be to say that you only need 35% of the key-space. I don't have a
feeling for how many global keys people bind by default, one would have
to study public configurations to find out. But I still remain sceptical
that -- compared to memory usage -- that need for keys is rising that
much.

>> I only know of Magit that does it, and as I have said before, I
>> think it is a mistake and unfriendly. But that still doesn't answer
>> the question. Why do you think that users expect it -- not the image
>> that magit has it it's users.
>>
>
> Being a programmer, I can understand your viewpoint.  As a user I
> can't. With M-x load-theme <something>, the user interface changes.

Well I install a package with M-x package-install, right? Not M-x
package-init or M-x package-load. When I install a program via my
package manager, I don't expect it to start immediately. It is just
expected that it is ready. And package-install does just that, and I
hope it is not just me, but that's what I would guess a command named
"package install" would do.

> What makes keybindings so different from user interface colors that
> they should absolutely not be touched when a package is loaded, say
> with M-x global-foobar-mode, and require an explicit manual
> configuration by the user?

A theme doesn't activate when it is installed or loaded, but when it is
activated. In the same way, I argue, a command shouldn't bind itself
until it is bound. Note that I don't insist that this has to be done
by editing your init.el (as shown in the patch from a few messages
before). I just think that loading a feature/package should attempt to
just load the package, without changing the UI/UX of the system.

> Do you also think it's a mistake and unfriendly if a package installs
> a menu item?  If not, what makes keybindings fundamentally different
> from menu items?

Do you mean a menu-bar-mode item? Yes, loading a package still shouldn't
change anything, activating a mode should add the menu item, so that it
is clear to the user what caused the change, and how it can be reversed.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

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

[Gregory Heytings]

>
> A theme doesn't activate when it is installed or loaded, but when it is 
> activated. In the same way, I argue, a command shouldn't bind itself 
> until it is bound. Note that I don't insist that this has to be done by 
> editing your init.el (as shown in the patch from a few messages before). 
> I just think that loading a feature/package should attempt to just load 
> the package, without changing the UI/UX of the system.
>

I fear you're splitting hairs here: the distinction between "install", 
"load" and "activate" is not important in this discussion, with the 
current state of affairs neither installing nor loading nor activating the 
package can automatically create a global key binding.  The proposal is an 
attempt to make that possible.

>> Do you also think it's a mistake and unfriendly if a package installs a 
>> menu item?  If not, what makes keybindings fundamentally different from 
>> menu items?
>
> Do you mean a menu-bar-mode item? Yes, loading a package still shouldn't 
> change anything, activating a mode should add the menu item
>

Okay, so if you agree that activating a mode can automatically add a menu 
bar item, why don't you agree that it should be possible to automatically 
add a global key binding while activating a mode?  Again, what makes key 
bindings fundamentally different from menu bar items?

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

[Robert Thorpe]

"Philip K." <philipk@posteo.net> writes:

> [1:text/plain Hide]
>
> Gregory Heytings <gregory@heytings.org> writes:
>
...
>> That reminds me the famous "640 kb should be enough for anyone" ;-)
>> Indeed, 26 letters is not enough.  Magit has three global commands, 
>> Org-mode has three, and Bookmark+ has three keymaps.  With just three
>> packages you've already used 35% of the available keys.  I hope you 
>> understand that it can't be a long-term solution.  Moreover, AFAIU,
>> packages cannot automatically bind their commands to C-c LETTER keys 
>> anyway: these keys are strictly reserved for users in their personal
>> configuration files.
>
> I think that's the pessimistic way to look at it, the optimistic one
> would be to say that you only need 35% of the key-space. I don't have a
> feeling for how many global keys people bind by default, one would have
> to study public configurations to find out. But I still remain sceptical
> that -- compared to memory usage -- that need for keys is rising that
> much.

Remember prefix keys here.  A user can define a prefix key anywhere in
the region reserved for users.

The manual says:

"A small number of keys are reserved for user-defined bindings, and
should not be used by modes, so key bindings using those keys are safer
in this regard.  The reserved key sequences are those consisting of
‘C-c’ followed by a letter (either upper or lower case), and function
keys <F5> through <F9> without modifiers (*note Modifier Keys::)."

It does not ban using those keys as prefixes.  I can make <F9> a prefix,
then I have the full keyboard to play with once again once I've pressed
F9.

BR,
Robert Thorpe

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

[Alfred M. Szmidt]

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

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

[Robert Pluim]

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

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

[Jean Louis]

* 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

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

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 2272 bytes --]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> "Philip K." <philipk@posteo.net> writes:
>
>> [1:text/plain Hide]
>>
>> Gregory Heytings <gregory@heytings.org> writes:
>>
> ...
>>> That reminds me the famous "640 kb should be enough for anyone" ;-)
>>> Indeed, 26 letters is not enough.  Magit has three global commands, 
>>> Org-mode has three, and Bookmark+ has three keymaps.  With just three
>>> packages you've already used 35% of the available keys.  I hope you 
>>> understand that it can't be a long-term solution.  Moreover, AFAIU,
>>> packages cannot automatically bind their commands to C-c LETTER keys 
>>> anyway: these keys are strictly reserved for users in their personal
>>> configuration files.
>>
>> I think that's the pessimistic way to look at it, the optimistic one
>> would be to say that you only need 35% of the key-space. I don't have a
>> feeling for how many global keys people bind by default, one would have
>> to study public configurations to find out. But I still remain sceptical
>> that -- compared to memory usage -- that need for keys is rising that
>> much.
>
> Remember prefix keys here.  A user can define a prefix key anywhere in
> the region reserved for users.
>
> The manual says:
>
> "A small number of keys are reserved for user-defined bindings, and
> should not be used by modes, so key bindings using those keys are safer
> in this regard.  The reserved key sequences are those consisting of
> ‘C-c’ followed by a letter (either upper or lower case), and function
> keys <F5> through <F9> without modifiers (*note Modifier Keys::)."
>
> It does not ban using those keys as prefixes.  I can make <F9> a prefix,
> then I have the full keyboard to play with once again once I've pressed
> F9.

Sure, but if we are assuming that packages either automatically or
semi-automatically bind keys, they would have to mutually respect their
prefix keys. The guideline would have to be that e.g. C-α [letter] has
to be a map, and that package are only allowed to bind keys to these.

Also, I don't think package developers would want to comply if they had
to use a less ergonomic key such as <F5-9>, undermining the entire plan.

> BR,
> Robert Thorpe

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

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

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 4374 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>> A theme doesn't activate when it is installed or loaded, but when it
>> is activated. In the same way, I argue, a command shouldn't bind
>> itself until it is bound. Note that I don't insist that this has to
>> be done by editing your init.el (as shown in the patch from a few
>> messages before). I just think that loading a feature/package should
>> attempt to just load the package, without changing the UI/UX of the
>> system.
>
> I fear you're splitting hairs here: the distinction between "install",
> "load" and "activate" is not important in this discussion, with the 
> current state of affairs neither installing nor loading nor activating
> the package can automatically create a global key binding.  The
> proposal is an attempt to make that possible.

Well none of these should so it, with the possible exception of
activating, that I'll mention again below. But I still think that the
distinction is important, if only because it is real. I recently
realized there would be another problem with this approach, as you also
mentioned that global modes should activate themselves on installation,
specifically naming Ivy, the completing-read framework. But what if
someone decides to install Helm? Will these two modes now interfere,
possibly breaking everything, or is it Helm's responsibility to
deactivate Ivy. If so, does every completion framework have to know
about every other one?

I think this shows that adding code like

        ;;;###autoload
        (ivy-mode t)

is bad style, even if a beginner manages to deactivate Ivy or Helm, the
same issue would arise every time Emacs is restarted, which creates the
feeling that the entire system is fragile -- and it is, because
fundamental operations like "install", "load" and "activate" are kept
apart.

As for key-bindings, if we assume that like Magit, any package can just
autoload a global-set-key, we are just inviting bug-reports complaining
about "Key sequence [something] starts with non-prefix key [something
else]", or key-bindings being over-ridden or chaining from session to
session.

Situations like these, tell me that adding user-customization directly
as autoloaded code is harmful and would at least require a level of
abstraction in-between.

>>> Do you also think it's a mistake and unfriendly if a package
>>> installs a menu item?  If not, what makes keybindings fundamentally
>>> different from menu items?
>>
>> Do you mean a menu-bar-mode item? Yes, loading a package still
>> shouldn't change anything, activating a mode should add the menu
>> item
>
> Okay, so if you agree that activating a mode can automatically add a
> menu bar item, why don't you agree that it should be possible to
> automatically add a global key binding while activating a mode?
> Again, what makes key bindings fundamentally different from menu bar
> items?

Activating a mode and deactivating a mode are "inverse" operations. This
is important, because it makes mode activation reversible, and lets the
user feel like he or she is in control. Therefore, if a
global-minor-mode, which I assume we are talking about, binds a global
key, it must not only un-bind it when it is done, but restore the
previous binding, if there was one. The tricky part is now if a second
global-minor-mode comes along, and wants to rebind the same key, also
saves the same command and then installs it's command: Now deactivating
the first mode would either have to check if the key it has bound is
still bound, and only undo it's operation if that is the case, or it
just re-binds the old key, overriding the binding of the second minor
mode. Neither of these are good approaches, and they cannot be resolved
without both global-minor-modes either knowing details about one-another
or having a protocol they follow to save keys.

The difference to menu items is that collisions like these are not
possible, you just add and remove an item from a list, without having to
fear collision (with the possible exception of having two items have the
same name, but that's an issue on a different level).

This demonstrates why a mode binding a key to the global-map is
difficult, and why it should instead use it's own map, that is installed
when said mode is activated.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

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

[Gregory Heytings]

>> I fear you're splitting hairs here: the distinction between "install", 
>> "load" and "activate" is not important in this discussion, with the 
>> current state of affairs neither installing nor loading nor activating 
>> the package can automatically create a global key binding.  The 
>> proposal is an attempt to make that possible.
>
> Well none of these should so it, with the possible exception of 
> activating, that I'll mention again below. But I still think that the 
> distinction is important, if only because it is real. I recently 
> realized there would be another problem with this approach, as you also 
> mentioned that global modes should activate themselves on installation, 
> specifically naming Ivy, the completing-read framework. But what if 
> someone decides to install Helm? Will these two modes now interfere, 
> possibly breaking everything, or is it Helm's responsibility to 
> deactivate Ivy. If so, does every completion framework have to know 
> about every other one?
>

That question and the problems you raise are orthogonal to the problem at 
hand.  I did not say that the distinction isn't important in general, only 
that it isn't relevant for the problem that the proposal attempts to 
solve.

I have no opinion about whether it is better for packages to install 
global bindings at installation time, at loading time or at activation 
time.  At first sight it seems to me that all three could make sense, 
depending on the package.

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

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>> Well none of these should so it, with the possible exception of
>> activating, that I'll mention again below. But I still think that
>> the distinction is important, if only because it is real. I recently 
>> realized there would be another problem with this approach, as you
>> also mentioned that global modes should activate themselves on
>> installation, specifically naming Ivy, the completing-read
>> framework. But what if someone decides to install Helm? Will these
>> two modes now interfere, possibly breaking everything, or is it
>> Helm's responsibility to deactivate Ivy. If so, does every
>> completion framework have to know about every other one?
>
> That question and the problems you raise are orthogonal to the problem
> at hand.  I did not say that the distinction isn't important in
> general, only that it isn't relevant for the problem that the proposal
> attempts to solve.
>
> I have no opinion about whether it is better for packages to install
> global bindings at installation time, at loading time or at activation 
> time.  At first sight it seems to me that all three could make sense,
> depending on the package.

I do think that the problems are relevant, because they show that
activation at install- or load-time are bad style. The only real choice
is activation-time, but that won't work for examples like Magit, since
they are not activated using modes. I'm not sure how I'd feel about a
magit-global-mode...

The only real solution that I see is something along the lines of what I
recommended: Packages suggest customizations, and package-install may
either ignore, ask for confirmation or accept them by default, if there
are no problems with what is suggested (eg. collisions). This avoids all
of the issues I have mentioned, will make it easier for newcomers
without annoying existing users, at minimal expense to package
maintainers, while providing information that can even be used by other
third-party packages (e.g. use-package can use the suggestions to
automatically build a configuration block).

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

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

[Gregory Heytings]

>> I have no opinion about whether it is better for packages to install 
>> global bindings at installation time, at loading time or at activation 
>> time.  At first sight it seems to me that all three could make sense, 
>> depending on the package.
>
> I do think that the problems are relevant, because they show that 
> activation at install- or load-time are bad style. The only real choice 
> is activation-time, but that won't work for examples like Magit, since 
> they are not activated using modes. I'm not sure how I'd feel about a 
> magit-global-mode...
>

As I said, I have no opinion about which moment is better.  But it seems 
to me that "the only real choice is activation-time" is wrong.  It depends 
on how much that package modifies the user interface.  Magit is a good 
example in that respect: nothing is changed, except three global key 
bindings.  There are other cases, imagine a package implementing a global 
command to query the stock price of the string under point to display it 
in the minibuffer.  It would make sense that installing that package 
binds, say, "C-\alpha $" to its command "display-stock-price", if that key 
is still available, without asking the user whether they really want that 
binding.  Other package authors may prefer to delay that binding until the 
package is loaded with a "require" or "load".  Yet others may prefer to 
delay that binding until the package is explicitly activated with M-x or 
in the users' init file.

>
> The only real solution that I see is something along the lines of what I 
> recommended: Packages suggest customizations, and package-install may 
> either ignore, ask for confirmation or accept them by default, if there 
> are no problems with what is suggested (eg. collisions).
>

And that solution cannot be implemented if there is no key space reserved 
for third-party libraries.  Which is what the proposal is about.  The 
proposal is not about the particular mechanisms that could be used to bind 
keys in that reserved area.

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

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>> The only real solution that I see is something along the lines of
>> what I recommended: Packages suggest customizations, and
>> package-install may either ignore, ask for confirmation or accept
>> them by default, if there are no problems with what is suggested
>> (eg. collisions).
>
> And that solution cannot be implemented if there is no key space
> reserved for third-party libraries.  Which is what the proposal is
> about.  The proposal is not about the particular mechanisms that could
> be used to bind keys in that reserved area.

I argue it can be done, and that the proposal to have packages suggest
keys to bind would avoid the need to designate a special key space for
third-party packages. That is why I'm brining it up.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

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

[Alfred M. Szmidt]

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

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

[Gregory Heytings]

>>> The only real solution that I see is something along the lines of what 
>>> I recommended: Packages suggest customizations, and package-install 
>>> may either ignore, ask for confirmation or accept them by default, if 
>>> there are no problems with what is suggested (eg. collisions).
>>
>> And that solution cannot be implemented if there is no key space 
>> reserved for third-party libraries.  Which is what the proposal is 
>> about.  The proposal is not about the particular mechanisms that could 
>> be used to bind keys in that reserved area.
>
> I argue it can be done, and that the proposal to have packages suggest 
> keys to bind would avoid the need to designate a special key space for 
> third-party packages.
>

I must have misunderstood something in your solution.  What are the 
possible keys a package could suggest, with your solution?  What is the 
set of keys in which package developers can choose keys to suggest to 
their users?

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

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 4172 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>>> The only real solution that I see is something along the lines of
>>>> what I recommended: Packages suggest customizations, and
>>>> package-install may either ignore, ask for confirmation or accept
>>>> them by default, if there are no problems with what is suggested
>>>> (eg. collisions).
>>>
>>> And that solution cannot be implemented if there is no key space
>>> reserved for third-party libraries.  Which is what the proposal is 
>>> about.  The proposal is not about the particular mechanisms that
>>> could be used to bind keys in that reserved area.
>>
>> I argue it can be done, and that the proposal to have packages
>> suggest keys to bind would avoid the need to designate a special key
>> space for third-party packages.
>
> I must have misunderstood something in your solution.  What are the
> possible keys a package could suggest, with your solution?  What is
> the set of keys in which package developers can choose keys to suggest
> to their users?

My apologies if I was unclear, I'll try to rephrase it so that you
understand where I'm coming from (and sorry, again, for the wall of
text):

Beginning from the fact, that I don't see any key that is common, unused
AND practical, I think we must accept that packages are actually limited
to those keys reserved for users (or user-configurations).

Usually, packages like Magit, Org, elfeed, etc. can only informally
propose a key-binding to use, users have to read this and install it
themselves. Works for you and me, but can be confusing to others.

My suggestion is based on the introduction of two variables: One for
packages to formally specify their suggestions for what keys to bind,
what hooks to modify, what options to set, etc. and one for users to
declare if they are interested or not.

The patch I added to a message proposed that eg. Magit wouldn't write
something like

        ;;;###autoload
        (global-set-key (kbd "C-x g") #'magit-status)

(I'm oversimplifying, their code is more complex), but instead they add
a line like

        ;;;###autoload
        (add-to-list 'pacakge-configuration-suggestions
                     '(magit            ; package name
                       (key             ; what type of suggestion 
                        "C-x g"         ; what key to bind the following to
                        magit-status    ; what command to bind
                        )))

This is one way, another one would be to use the header, but that's a
bit more complicated.

Now that the package has been installed and the suggestion has been
noted, Emacs would check a user-option I've named
`package-ignore-suggestions' but could be more general if the user is
interested in recommended key-binding suggestions. If this is the case,
package-install would immediately query ask the user if something like

                (global-set-key (kbd "C-x g") #'magit-status)

should be added to the user configuration. In my patch this was just a
yes or no question, but a more serious implementation could also
support a list of key-chords, only suggesting those that have not been
bound yet, and allowing the user to set their own key-binding. Ideally,
every suggestion should also have a justification explaining why it
proposes this modification.

As I've implied, `package-ignore-suggestions' could be transformed to
just accept anything a package proposes, notifying the user that after
installing, e.g. Magit, C-x g has been bound.

So, this modifies as little as possible (just noting suggestions that
don't interest the user) in a program-friendly format that can be
expanded to code in the user-configuration. This can then be modified,
and these configurations wouldn't be changed by package
updated. Package.el ensures that the user isn't confused, is notified of
changes and gets to decide what he or she wants. 

It seems to me that this is the minimal abstraction layer necessary for
packages to configure themselves while maintaining good style, or at
least what I understand good style to be.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

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

[Gregory Heytings]

Thanks for your detailed answer!

>
> Beginning from the fact, that I don't see any key that is common, unused 
> AND practical, I think we must accept that packages are actually limited 
> to those keys reserved for users (or user-configurations).
>

Well, that's exactly what the proposal attempts to fix ;-)

>
> Usually, packages like Magit, Org, elfeed, etc. can only informally 
> propose a key-binding to use, users have to read this and install it 
> themselves. Works for you and me, but can be confusing to others.
>

Yes, exactly.

>
> My suggestion is based on the introduction of two variables: One for 
> packages to formally specify their suggestions for what keys to bind, 
> what hooks to modify, what options to set, etc. and one for users to 
> declare if they are interested or not.
>
> The patch I added to a message proposed that eg. Magit wouldn't write 
> something like
>
>        ;;;###autoload
>        (global-set-key (kbd "C-x g") #'magit-status)
>
> (I'm oversimplifying, their code is more complex), but instead they add 
> a line like
>
>        ;;;###autoload
>        (add-to-list 'pacakge-configuration-suggestions
>                     '(magit            ; package name
>                       (key             ; what type of suggestion
>                        "C-x g"  ; what key to bind the following to
>                        magit-status ; what command to bind
>                       )))
>

I'm fine with this in principle, but it doesn't answer the question.  In 
the above example Magit would suggest "C-x g".  It can do this because at 
the moment that key isn't used by Emacs.  There is no guarantee that that 
key will not at some point be reclaimed by Emacs.  It cannot suggest a 
"C-c LETTER" key, these are AFAIU strictly reserved for users in their 
configuration files, and there are not enough available keys there so this 
cannot be a long term solution anyway.  So what keys can it suggest? 
This, and only this, is what the proposal is about.

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

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>> My suggestion is based on the introduction of two variables: One for
>> packages to formally specify their suggestions for what keys to
>> bind, what hooks to modify, what options to set, etc. and one for
>> users to declare if they are interested or not.
>>
>> The patch I added to a message proposed that eg. Magit wouldn't
>> write something like
>>
>>        ;;;###autoload
>>        (global-set-key (kbd "C-x g") #'magit-status)
>>
>> (I'm oversimplifying, their code is more complex), but instead they
>> add a line like
>>
>>        ;;;###autoload
>>        (add-to-list 'pacakge-configuration-suggestions
>>                     '(magit            ; package name
>>                       (key             ; what type of suggestion
>>                        "C-x g"  ; what key to bind the following to
>>                        magit-status ; what command to bind
>>                       )))
>>
>
> I'm fine with this in principle, but it doesn't answer the question.
> In the above example Magit would suggest "C-x g".  It can do this
> because at the moment that key isn't used by Emacs.  There is no
> guarantee that that key will not at some point be reclaimed by Emacs.
> It cannot suggest a "C-c LETTER" key, these are AFAIU strictly
> reserved for users in their configuration files, and there are not
> enough available keys there so this cannot be a long term solution
> anyway.  So what keys can it suggest? This, and only this, is what the
> proposal is about.

My reading of the guideline on "C-c LETTER" is that a major/minor mode
shouldn't bind C-c LETTER to a command, so that it overshadows whatever
is bound globally to C-c LETTER. But a system like what I propose just
generates to configuration *for* the user, in a user file in which case
the guideline doesn't apply. That's what I mean by avoiding the need for
an extra key-space.

Of course, if some way could be found to reserve a prefix for
third-party packages, pacakge-configuration-suggestions could always
use this too -- my suggestion just anticipates that this will probably
not happen and tries to solve the problem in a different way.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

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

[Gregory Heytings]

>
> My reading of the guideline on "C-c LETTER" is that a major/minor mode 
> shouldn't bind C-c LETTER to a command, so that it overshadows whatever 
> is bound globally to C-c LETTER. But a system like what I propose just 
> generates to configuration *for* the user, in a user file in which case 
> the guideline doesn't apply. That's what I mean by avoiding the need for 
> an extra key-space.
>

I'm not sure your interpetation of that guideline ("Don't define 'C-c 
LETTER' as a key in Lisp programs") is correct, but now at least I see 
what you mean: you're more or less cheating the guideline by generating a 
configuration file, after asking the user if they're okay with that, 
instead of binding the key directly in the package depending on the value 
of a configuration variable.  To me what you propose looks pretty close to 
using customize to set a foobar-set-global-binding variable that would be 
used in a call to global-set-key.

And that doesn't solve the problem that 26 letter keys is a small number. 
Yes, you can also use capital letters, and yes, you can put keymaps on 
these 26 letters instead of single commands.  IMO, that can't work as a 
long-term solution; if it were, it would already be used, and the fact is 
that it isn't, and that third-party packages prefer to use, or recommend 
to use, keys that are not yet bound by Emacs.

>
> Of course, if some way could be found to reserve a prefix for 
> third-party packages,
>

Again: this, to reserve prefix key(s) for third-party packages, and only 
this, is what the proposal is about.

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

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>> My reading of the guideline on "C-c LETTER" is that a major/minor
>> mode shouldn't bind C-c LETTER to a command, so that it overshadows
>> whatever is bound globally to C-c LETTER. But a system like what I
>> propose just generates to configuration *for* the user, in a user
>> file in which case the guideline doesn't apply. That's what I mean
>> by avoiding the need for an extra key-space.
>>
>
> I'm not sure your interpetation of that guideline ("Don't define 'C-c
> LETTER' as a key in Lisp programs") is correct, but now at least I see 
> what you mean: you're more or less cheating the guideline by
> generating a configuration file, after asking the user if they're okay
> with that, instead of binding the key directly in the package
> depending on the value of a configuration variable.  To me what you
> propose looks pretty close to using customize to set a
> foobar-set-global-binding variable that would be used in a call to
> global-set-key.

Yes, that could also be done, the precise code that is generated is an
open question

> And that doesn't solve the problem that 26 letter keys is a small
> number. Yes, you can also use capital letters, and yes, you can put
> keymaps on these 26 letters instead of single commands.  IMO, that
> can't work as a long-term solution; if it were, it would already be
> used, and the fact is that it isn't, and that third-party packages
> prefer to use, or recommend to use, keys that are not yet bound by
> Emacs.

You could use C-c LETTER as a fallback, and suggest more convenient keys
first, that are usually unbound. But even considering that, what do you
think that the long-term issue is? Do you think that with time, people
will be using more and more packages that need global keys?

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

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

[Richard Stallman]

[[[ 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)

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

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-13 00:49]:
> And that doesn't solve the problem that 26 letter keys is a small number.
> Yes, you can also use capital letters, and yes, you can put keymaps on these
> 26 letters instead of single commands.  IMO, that can't work as a long-term
> solution; if it were, it would already be used, and the fact is that it
> isn't, and that third-party packages prefer to use, or recommend to use,
> keys that are not yet bound by Emacs.

I see that combination already as huge one. I have my own packages
bound to prefix keys and I do use capital letters too like small
letter "l" in combination {C-c p l} I use to list people of certain
group but {C-c p L} I use to list all the recently entered people in
the database. Additionally to letters there are also various symbols,
so there are a lot of combinations. Then we have:

C-c LETTER (26 or more on international keyboards) x 2 (for capital letters) + number of symbols

than that is maybe approximately 60-70 keys, and if some of keys are
used as prefixes then we have 60 x 60 = 3600 possible keys roughly
estimated. Then if we add Super key to it, it becomes more than 7000
possible keys, if not 7500 or more.

Isn't that quite enough?

Then if third party package defines keys they could just say to user
"bind the map to any key you wish, we recommend C-c g" and the 40
commands used by third party package may be invoked by using C-c g
LETTER/SYMBOL

> Again: this, to reserve prefix key(s) for third-party packages, and only
> this, is what the proposal is about.

I think the proposal should say that reservation is meant for global
bindings by third party packages.

After consideration of many details I think that proposal is there to
solve specific problem, but that problem may not be solved anyway and
there are already various solutions to that problem even without the
proposal.

For example Magit did bind some keys and it works. There is no
problem. Those users who wish to change some keys they can adapt
little or replace some keys. But I don't think that proposal comes
from Magit developers, does it? So the solutions to that problem are
already in existence how I understand it.

Suggesting a prefix key to be bound by user on some of users' reserved
key is another solution as well.

In my opinion the number of possible keys is already over 7000,
probably even 10000 and more. Emacs would not so quickly use those
keys for itself.

For example none of Super key bindings is used by Emacs. That makes
alone possibly 7000-10000 possible combinations.

Reserving a key or keys by Emacs for general unknown third party
package would also require that there is some kind of a database of
reserved keys for various third party packages and such does not
exist. Similarly for /package or slash package enthusiasts which I am
one of them, there exists database of allocated package names:
https://cr.yp.to/slashpackage/list.html but in Emacs we do not have
the database of allocated key bindings for third party packages. So
third party packages may do anyway what they wish and want. Reserving
the key does not solve the randomity of plethora of combinations that
third party packages can invent and do, they may collide with each
other, they may use unused or used keys, combinations are too many.

Those who did understand conventions they did their best and already
provided solutions.

The solution should come from third party package in consensus with
the user who does the installation.

Solution to third party packages should not come from Emacs, as that
is what they are: third parties.

Then if we reserve let us say M-z for third party packages, then one
package will say I wish {M-z m} for command X, other package will say
they wish {M-z m} or command Y, so there is no benefit, again we have
numerous possible imaginary problems where there are no practical
problems. Solution to the problem of how third parties want to
function cannot possibly come from Emacs. Additionally third parties
are not controlled by Emacs development, they have zero obligation to
listen or to comply to it.

Those who do listen and comply will not have the database of allocated
key bindings and will have possible collision with other third party
packages. 

After the reservation of the key for third party package, then who is
to make the effort to inform all the thousands of developers of the
reservation? Reservation for packages requires informing people of
those reservations. Why would they comply? Emacs development is not
dictating how third parties should set their bindings.

We have seen here that users set their key bindings just how they
wish, somebody may remove C-o completely for something else, somebody
protests against this.

The pattern of key bindings by users is capricious. That is what we
can learn from discussion and the same capricious pattern is there
with third party packages.

Who would guarantee that third party packages would now use those
reserved keys and not set globally anyway otherwise reserved keys?

All for thinking.

Jean

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

[Gregory Heytings]

>> To me what you propose looks pretty close to using customize to set a 
>> foobar-set-global-binding variable that would be used in a call to 
>> global-set-key.
>
> Yes, that could also be done, the precise code that is generated is an 
> open question
>

But that would be forbidden by the guideline "Don't define 'C-c LETTER' as 
a key in Lisp programs", wouldn't it?

(defcustom foobar-global-key "" "Foobar global key in C-c")
...
(if (length foobar-global-key)
   (global-set-key (kbd (concat "C-c " foobar-global-key) 'foobar-foo-command)))

If that's allowed, then why not this?

(defcustom foobar-global-key "z" "Foobar global key in C-c")
...
(if (length foobar-global-key)
   (global-set-key (kbd (concat "C-c " foobar-global-key) 'foobar-foo-command)))

This is not very different from the first one, and does what the guideline 
forbids, but it could be argued that it does not because it does so only 
conditionally...

>
> But even considering that, what do you think that the long-term issue 
> is? Do you think that with time, people will be using more and more 
> packages that need global keys?
>

I do not think, I see.  Just have a look at the starter kits, or at the 
init files of those who make them public.  You'll see that there are many 
packages that need global keys.

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

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>> To me what you propose looks pretty close to using customize to set
>>> a foobar-set-global-binding variable that would be used in a call
>>> to global-set-key.
>>
>> Yes, that could also be done, the precise code that is generated is
>> an open question
>>
>
> But that would be forbidden by the guideline "Don't define 'C-c
> LETTER' as a key in Lisp programs", wouldn't it?

It seems to me that this is a matter of "in the word of the law" or "in
the spirit of the law". I understand the "spirit" of the guideline to be
saying that external code shouldn't try to bind keys that are reserved
for the users to decide what to bind. This is not because they are
external, but because they would make a decision for the user.

> (defcustom foobar-global-key "" "Foobar global key in C-c")
> ...
> (if (length foobar-global-key)
>   (global-set-key (kbd (concat "C-c " foobar-global-key) 'foobar-foo-command)))

This would be defined unconditionally too, I assume you wanted to set
the default value of foobar-global-key to nil and check if it is
non-nil. And even then, the binding should be done in the defcustom's
:set procedure, to make it reversible -- but that's not important here.

> If that's allowed, then why not this?
>
> (defcustom foobar-global-key "z" "Foobar global key in C-c")
> ...
> (if (length foobar-global-key)
>   (global-set-key (kbd (concat "C-c " foobar-global-key) 'foobar-foo-command)))
>
> This is not very different from the first one, and does what the
> guideline forbids, but it could be argued that it does not because it
> does so only conditionally...

Conditionally, yes, but also by *default*, which I think is the
problem. The default execution of this code would override whatever was
bound on C-c z, without asking the user -- and I see this as a violation
of guideline's "spirit".

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

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

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-13 11:34]:
> 
> > > To me what you propose looks pretty close to using customize to set
> > > a foobar-set-global-binding variable that would be used in a call to
> > > global-set-key.
> > 
> > Yes, that could also be done, the precise code that is generated is an
> > open question
> > 
> 
> But that would be forbidden by the guideline "Don't define 'C-c LETTER' as a
> key in Lisp programs", wouldn't it?

I think not, as that would not be automated global setting by the
package. User have got the control, user decided, not the package.

> (defcustom foobar-global-key "" "Foobar global key in C-c")
> ...
> (if (length foobar-global-key)
>   (global-set-key (kbd (concat "C-c " foobar-global-key)
> 'foobar-foo-command)))

I would rather keep that without C-c and just let user decide on the
prefix key which could be any. By inspecting already bound key, user
could by trial and error in the wizard choose other rater by user
unused key as prefix for the package.

Like this:

1. This program uses key bindings.

2. You will be asked to assign a prefix key for key bindings in this
   package.

3. We recommend that you assign C-c ANY-LETTER as a prefix key, but
   you may as well choose Super in combination with ANY-LETTER or M
   (Alternative) and so on. Please press the key that you think it
   could be prefix to this package's commands.

4. You have pressed C-x ; that is bound to `comment-set-column'. If
   you now accept C-x ; as prefix for package X, that command will not
   be available on that key any more. Are you sure? Yes or no?

   If not sure, we may recommend that you use C-c ; as prefix for this
   package, would that be fine?

   Continue the loop.

5. Thank you. Your prefix has been set on Super key and letter p. You
   may change "s-p" at any time in future to other prefix by invoking
   function M-x key-wizard-of-oz-for-package-X or by customizing the
   variable `package-X-prefix-key'

The function to assign the prefix key for a package could become Emacs
function so that any new package uses that function to assign the
prefix key for the package or to assign some keys for commands that
are not prefix keys. 

> > But even considering that, what do you think that the long-term issue
> > is? Do you think that with time, people will be using more and more
> > packages that need global keys?
> 
> I do not think, I see.  Just have a look at the starter kits, or at the init
> files of those who make them public.  You'll see that there are many
> packages that need global keys.

Let us have some names of packages to look at it.

Jean

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> C-c LETTER (26 or more on international keyboards) x 2 (for
> capital letters) + number of symbols
>
> than that is maybe approximately 60-70 keys, and if some of
> keys are used as prefixes then we have 60 x 60 = 3600
> possible keys roughly estimated. Then if we add Super key to
> it, it becomes more than 7000 possible keys, if not 7500 or
> more [...]
>
> In my opinion the number of possible keys is already over
> 7000, probably even 10000 and more. Emacs would not so
> quickly use those keys for itself.
>
> For example none of Super key bindings is used by Emacs.
> That makes alone possibly 7000-10000 possible combinations.

Unheard of.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

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

[Gregory Heytings]

>> But that would be forbidden by the guideline "Don't define 'C-c LETTER' 
>> as a key in Lisp programs", wouldn't it?
>
> It seems to me that this is a matter of "in the word of the law" or "in 
> the spirit of the law". I understand the "spirit" of the guideline to be 
> saying that external code shouldn't try to bind keys that are reserved 
> for the users to decide what to bind. This is not because they are 
> external, but because they would make a decision for the user.
>

Indeed, my understanding of the "spirit of the law" is different: my 
understanding is that no code in a library should bind C-c LETTER key, 
conditionally or not, and that these keys are strictly reserved for users, 
who have to explicitly bind them in their init file.

AFAIU, this is also how the author of Magit understands that guideline: 
Magit binds three keys globally unless magit-define-global-key-bindings, 
whose default value is t, has been set to nil, and only recommends in the 
docstring to bind "C-c g".  With your understanding of the guideline, 
Magit could have added a third possible to 
magit-define-global-key-bindings, say 'best, with which the "C-c g" 
binding would have been created automatically.

Anyway, that question is, as I said, unrelated to the proposal itself.

>> (defcustom foobar-global-key "" "Foobar global key in C-c")
>> ...
>> (if (length foobar-global-key)
>>   (global-set-key (kbd (concat "C-c " foobar-global-key) 'foobar-foo-command)))
>
> This would be defined unconditionally too
>

Whoops, I wrote too fast indeed, of course it should have been (if (> 
(length foobar-global-key) 0)..., or perhaps (unless (string-empty-p 
foobar-global-key)...

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

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-13 15:45]:
> > For example none of Super key bindings is used by Emacs.
> > That makes alone possibly 7000-10000 possible combinations.
> 
> Unheard of.

How about trying it?

If s-a is prefix key, 26 letters + 26 upper case letters + 10 numbers
plus 32 symbols on my keyboard is 94 combinations multiplied by 94
possible other following keys, not counting possible middle suffix
keys, yields ations is 8836 possible bindings with Super key on this
keyboard.

Make s-a prefix key:

s-a a
s-a b
s-a 1
s-a 2
s-a !
etc.

Make s-A prefix key:

s-A a
s-A b
s-A 1
s-A 2
s-A !
etc.

Then continue for each key as prefix key and multiply by other
combinations. I think 8836 minimum is here. International keyboards
could have more than that.

Example binding that works:

(global-set-key (kbd "s-U u") (lambda () (interactive) (message "Hello")))

Then if we add combinations with Control on my keyboard that becomes
94 x 94 x 94 with Control, so there are 830584 possible key bindings
by using Super key and Super combined with Control key.

Example binding:

(global-set-key (kbd "C-s-b i") (lambda () (interactive) (message "Hello")))

Super can be combined with Meta or Alternative key. So that adds
another multiplication by 94 and we end up with 78,074,896 possible
key bindings that use Super key.

Example bindings:

(global-set-key (kbd "M-s-b b") (lambda () (interactive) (message "Hello")))

(global-set-key (kbd "M-s-b C-s-c") (lambda () (interactive) (message "Hello")))

(global-set-key (kbd "M-s-b M-s-7") (lambda () (interactive) (message "Hello")))

If we then make the second key also prefix the number of possible
bindings grows and grows.

If my calculation is wrong, then please make your own calculation and
make cross checks to verify it and post it here.

As currently we have situation that some people will say that Super
often collides with Window Manager, but is that often more than 94
combinations by 94 combinations?

If s-p collides then maybe s-; does not. If s-; is prefix key that
alone opens 94 possible combinations on this keyboard. If I wish I
could use a middle prefix key in that combination and get 8836
combinations.

Example where s-; a is prefix key:

(global-set-key (kbd "s-; a 1") (lambda () (interactive) (message "Hello")))
(global-set-key (kbd "s-; a 2") (lambda () (interactive) (message "Hello")))
(global-set-key (kbd "s-; a 3") (lambda () (interactive) (message "Hello")))
(global-set-key (kbd "s-; b 1") (lambda () (interactive) (message "Hello")))
(global-set-key (kbd "s-; B 1") (lambda () (interactive) (message "Hello there")))

The demonstration is there to show that combinations are more or less
endless. I have no problem using s-; B 1 or remembering it. It is
nothing less usable than C-x 5 0 or similar known commands.

C-x 8 ' U gives me in Emacs = Ú -- so if I need that I will
remember. I often use C-x 8 L to specify pounds as money symbol like
£200 and I remember it. Personally I use C-x 7 as prefix for years
already. C-x 9 is also free.

Problem is in console, but maybe that problem can be solved. What you
think how to solve Super key in console? Maybe kernel developers need
to be contacted?

We justdid not find how. That it can be solved is already clear as
Super does work in X, so detection will work in console but it could
be that it was tradiitonally just forgotten. Virtually all users have
today Super key. If they change it in kernel then Super key becomes
really super.

Jean

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

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]


Sorry for protracting the conversation, I just think the interpretation
of the guideline is important.

Gregory Heytings <gregory@heytings.org> writes:

>>> But that would be forbidden by the guideline "Don't define 'C-c
>>> LETTER' as a key in Lisp programs", wouldn't it?
>>
>> It seems to me that this is a matter of "in the word of the law" or
>> "in the spirit of the law". I understand the "spirit" of the
>> guideline to be saying that external code shouldn't try to bind keys
>> that are reserved for the users to decide what to bind. This is not
>> because they are external, but because they would make a decision
>> for the user.
>
> Indeed, my understanding of the "spirit of the law" is different: my
> understanding is that no code in a library should bind C-c LETTER key, 
> conditionally or not, and that these keys are strictly reserved for
> users, who have to explicitly bind them in their init file.

This seems to be more of a literal interpretation, unless I'm missing
something. When talking about the "spirit of the law", I'm trying to
consider why a key-space would have been reserved for users. Or to put
it this way, the problem that the guideline tries to prevent is
primarily that {minor,major} modes don't shadow certain keys, and
secondarily that libraries don't override these same keys. I distinguish
between primary and secondary motivations, because the latter is
something that should be avoided in the first place, no matter what key
is bound.

Because what difference does it make who binds the key, or where it is
bound? You could have a function like

        (defun foo-bind-to (key)
          (global-set-key (kbd key) #'foo-function))

even though it is nonsensical, it violates what I consider the literal
interpretation (global-set-key is called from a library), but not how
I'm reading it (the user decides to call foo-bind-to, and might pass a
C-c LETTER for KEY).

> AFAIU, this is also how the author of Magit understands that
> guideline: Magit binds three keys globally unless
> magit-define-global-key-bindings, whose default value is t, has been
> set to nil, and only recommends in the docstring to bind "C-c g".
> With your understanding of the guideline, Magit could have added a
> third possible to magit-define-global-key-bindings, say 'best, with
> which the "C-c g" binding would have been created automatically.

No, because the user is not asked, and I have to add extra
configuration, to prevent Magit from changing my environment. This all
boils down to the question of what's better: Opt-in or Out-out -- I have
argued that these kind of things (modes, binding global keys, hook, ...)
should always be opt-in. What is ultimately considered good style is up
to the users to decide, but I'm not a fan of a configuration where most
of everything is just deactivating defaults.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

Philip Kaludercic wrote:

> (defun foo-bind-to (key)
>   (global-set-key (kbd key) #'foo-function))
>
> even though it is nonsensical, it violates what I consider
> the literal interpretation (global-set-key is called from
> a library)

What is a library all of a sudden? A package?

There is nothing wrong with having Elisp help you assign keys.

On the contrary, that's how it is done :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

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

[Gregory Heytings]

>
> Sorry for protracting the conversation, I just think the interpretation 
> of the guideline is important.
>

Not for the proposal itself.

>> Indeed, my understanding of the "spirit of the law" is different: my 
>> understanding is that no code in a library should bind C-c LETTER key, 
>> conditionally or not, and that these keys are strictly reserved for 
>> users, who have to explicitly bind them in their init file.
>
> This seems to be more of a literal interpretation, unless I'm missing 
> something.
>

Yes, indeed.

>> AFAIU, this is also how the author of Magit understands that guideline: 
>> Magit binds three keys globally unless 
>> magit-define-global-key-bindings, whose default value is t, has been 
>> set to nil, and only recommends in the docstring to bind "C-c g". With 
>> your understanding of the guideline, Magit could have added a third 
>> possible to magit-define-global-key-bindings, say 'best, with which the 
>> "C-c g" binding would have been created automatically.
>
> No, because the user is not asked, and I have to add extra 
> configuration, to prevent Magit from changing my environment.
>

The point here is that the three values for 
magit-define-global-key-bindings would have resulted in three behaviors: 
nil => do not bind any key, t => bind keys but not in C-c, 'best => bind 
keys including one in C-c.  The author of Magit did not do this, so my 
guess (it's just a guess, I could be wrong) is that he also has a literal 
interpretation of the guideline.

>
> This all boils down to the question of what's better: Opt-in or Out-out 
> -- I have argued that these kind of things (modes, binding global keys, 
> hook, ...) should always be opt-in.
>

This question comes closer to the proposal, I understand your point, and I 
do not agree.  As I said, you and me are developers, we know Emacs, we 
know how it works, we know how to do things.  Newcomers are perhaps not 
even developers, and even those who are shouln't have to do such things, 
just as you shouldn't have to add some JavaScript code in a configuration 
file of your browser to enable an extension.  Here's how the author of 
Magit explained why he added global bindings:

"Some [...] beginners will initially have a low threshold for things not 
working out of the box and I don't want to (continue to) scare them off by 
immediately forcing them to learn how to add key bindings and what that 
even means.  There's a lot of talk about making Emacs friendlier for 
beginners and this is a small step in that direction." [1]

The proposal goes exactly into that same direction, and has the same 
motivation.

[1] https://github.com/magit/magit/pull/4237#issuecomment-723495053

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> If s-a is prefix key, 26 letters + 26 upper case letters +
> 10 numbers plus 32 symbols on my keyboard is 94 combinations
> multiplied by 94 possible other following keys, not counting
> possible middle suffix keys, yields ations is 8836 possible
> bindings with Super key on this keyboard.

Are you trying to compute the total number of keybindings?

What do you mean by "middle suffix keys"?

What is the Super key? A modifier like C and M? Here are
a bunch of standards:

  https://en.wikipedia.org/wiki/ISO/IEC_9995

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

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

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-13 18:03]:
> "Some [...] beginners will initially have a low threshold for things not
> working out of the box and I don't want to (continue to) scare them off by
> immediately forcing them to learn how to add key bindings and what that even
> means.  There's a lot of talk about making Emacs friendlier for beginners
> and this is a small step in that direction." [1]
> 
> The proposal goes exactly into that same direction, and has the same
> motivation.
> 
> [1] https://github.com/magit/magit/pull/4237#issuecomment-723495053

"Emacs functions are defined within parenthesis like ( and ). The
items withn parenthesis are a list. That is why LISP as programming
language means LISt Processing. At first place of the list user would
give a command to computer such as `global-set-key' and at next
following places various parameters to the command.

Following LISP expression would place `magit-function' on the key
Control-c followed by the letter m.

(global-set-key (kbd "C-c m") 'magit-function)"

The above is my attempt to describe how one could describe a function.

Describing a function to teach users is equally costly effort just as
it is explaining how users need not be teached anything and treat them
as not very bright (mildly said).

Again:

> "Some [...] beginners will initially have a low threshold for things not
> working out of the box and I don't want to (continue to) scare them off by
> immediately forcing them to learn how to add key bindings and what that even
> means.  There's a lot of talk about making Emacs friendlier for beginners
> and this is a small step in that direction." [1]

So that comes from Magit? How can version control system developer
treat their users as not being very bright (I am just deliberately
avoiding saying "stupid")? Makes no logic to me.

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

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-13 18:10]:
> Jean Louis wrote:
> 
> > If s-a is prefix key, 26 letters + 26 upper case letters +
> > 10 numbers plus 32 symbols on my keyboard is 94 combinations
> > multiplied by 94 possible other following keys, not counting
> > possible middle suffix keys, yields ations is 8836 possible
> > bindings with Super key on this keyboard.
> 
> Are you trying to compute the total number of keybindings?
> 
> What do you mean by "middle suffix keys"?

That was mistake, sharp-eye. I was meaning prefix after prefix.

When s-p is prefix one can make s-p p also prefix, that increases
rapidly number of available keys. I favor prefixes like

MODIFIER-LETTER SAME-LETTER-AGAIN as such can be invoked quicker.

> What is the Super key? A modifier like C and M? Here are
> a bunch of standards:
> 
>   https://en.wikipedia.org/wiki/ISO/IEC_9995

Solution to make Super key work in console shall be
practical. Do you have more specific reference?

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> Emacs functions are defined within parenthesis like
> ( and ). The items withn parenthesis are a list. [...]

Well, in some sense I suppose, but technically, actually not
so:

(listp (defun dummy-function ()
         (message "darn good software") )) ; nil

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> When s-p is prefix one can make s-p p also prefix, that
> increases rapidly number of available keys. I favor prefixes
> like

Suggestion, start with: what are the number of keybindings if
there are no additional prefix keys defined, with modifiers are
C and M?

> MODIFIER-LETTER SAME-LETTER-AGAIN as such can be
> invoked quicker.

Well, for the first and most important one, sure. Then the
asdf jkl; keys as they are close and fast and ergonomic, then
the ... etc

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Nothing is the list - Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-13 18:31]:
> Jean Louis wrote:
> 
> > Emacs functions are defined within parenthesis like
> > ( and ). The items withn parenthesis are a list. [...]
> 
> Well, in some sense I suppose, but technically, actually not
> so:
> 
> (listp (defun dummy-function ()
>          (message "darn good software") )) ; nil

That is tricky question.

Anything or nothing between parenthesis is a list.

That it is TRUE that nothing between parenthesis is something, in this
case a list is proven by your similar example of yours:

(listp ()) => t

That sometimes something which is not nothing between the list cannot
be list is proven by your own example:

(listp (defun dummy-function ()
          (message "darn good software"))) => nil

So nothing is a list but something in that list becomes sometimes not a list.

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

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-13 18:39]:
> Jean Louis wrote:
> 
> > When s-p is prefix one can make s-p p also prefix, that
> > increases rapidly number of available keys. I favor prefixes
> > like
> 
> Suggestion, start with: what are the number of keybindings if
> there are no additional prefix keys defined, with modifiers are
> C and M?

So just to count number of keys without using those keys as prefix
keys?

And then just one shall be reserved for third party packages? And not
as prefix?

Is that what was meant with it?

Those third party packages may start fighting for that one reserved
key.

> > MODIFIER-LETTER SAME-LETTER-AGAIN as such can be
> > invoked quicker.
> 
> Well, for the first and most important one, sure. Then the
> asdf jkl; keys as they are close and fast and ergonomic, then
> the ... etc

In modal mode Emacs offers probably better keybindings like Xah
explained: https://github.com/xahlee/xah-fly-keys

We still think that the key need be reserved, but we forgot the
growing number of vi-like users who prefer modal system. 

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

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Philip Kaludercic wrote:
>
>> (defun foo-bind-to (key)
>>   (global-set-key (kbd key) #'foo-function))
>>
>> even though it is nonsensical, it violates what I consider
>> the literal interpretation (global-set-key is called from
>> a library)
>
> What is a library all of a sudden? A package?

Oops, yes, I meant a package.

> There is nothing wrong with having Elisp help you assign keys.
>
> On the contrary, that's how it is done :)

My point was if a package provides function as the one above, you'd be
able to write

        (foo-bind-to "C-c a")

instead of

        (global-set-key (kbd "C-c a") #'foo-function)

which probably isn't worth it.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

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

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> Sorry for protracting the conversation, I just think the
>> interpretation of the guideline is important.
>>
>
> Not for the proposal itself.

Well yes, because if packages may bind to C-c *with* the consent of
users, the need for a special package map decreases.

>>> AFAIU, this is also how the author of Magit understands that
>>> guideline: Magit binds three keys globally unless 
>>> magit-define-global-key-bindings, whose default value is t, has
>>> been set to nil, and only recommends in the docstring to bind "C-c
>>> g". With your understanding of the guideline, Magit could have
>>> added a third possible to magit-define-global-key-bindings, say
>>> 'best, with which the "C-c g" binding would have been created
>>> automatically.
>>
>> No, because the user is not asked, and I have to add extra
>> configuration, to prevent Magit from changing my environment.
>
> The point here is that the three values for
> magit-define-global-key-bindings would have resulted in three
> behaviors: nil => do not bind any key, t => bind keys but not in C-c,
> 'best => bind keys including one in C-c.  The author of Magit did not
> do this, so my guess (it's just a guess, I could be wrong) is that he
> also has a literal interpretation of the guideline.

The way I see it is that there is no need for a value like 'best,
because this whole idea is that magit wants to bind their keys by
default, but it shouldn't bind it to C-c g. If you're going to set
magit-define-global-key-bindings to 'best, you might just as well
directly bind magit-status to C-c g. I think it would be totally ok for
Magit to have the default value set to nil, and then bind to C-c g, but
that undermines their entire motivation, as there would be no default
binding.

Btw., are there any other examples of packages binding global keys by
default?
 
-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

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

[Jean Louis]

* Philip Kaludercic <philipk@posteo.net> [2021-02-13 23:15]:
> Btw., are there any other examples of packages binding global keys by
> default?

Searching through my ~/.emacs.d/elpa:

./keychain-environment-20180318.2223/all-the-icons-ivy-rich-20200830.1745.el\0641:
(global-set-key [remap kill-buffer]
#'all-the-icons-ivy-rich-kill-buffer)

./keychain-environment-20180318.2223/better-defaults-20200717.2012.el\071:
(global-set-key (kbd "C-x C-b") 'ibuffer)

etc.

./company-0.9.13/company-autoloads.el\0370:  (global-set-key (kbd \"C-c y\") \\='company-yasnippet)
./company-0.9.13/company-yasnippet.el\0151:  (global-set-key (kbd \"C-c y\") \\='company-yasnippet)

./info+-0/info+.el\02876:(global-set-key [remap info-emacs-manual]
'info-manual) ; `C-h r'

./winring-20180530.18/winring.el\0532:  (global-set-key winring-keymap-prefix winring-map))
./issn-verify-1.0.0/iscroll.el\0298:        (global-set-key [remap next-line] #'iscroll-next-line)
./issn-verify-1.0.0/iscroll.el\0299:        (global-set-key [remap previous-line]
./issn-verify-1.0.0/iscroll.el\0303:    (global-set-key [remap next-line] nil)
./issn-verify-1.0.0/iscroll.el\0304:    (global-set-key [remap previous-line] nil)))

Those are remappings but still..

./gnuplot-20200322.53/gnuplot-autoloads.el\075:     (global-set-key [(f10)] 'gnuplot-make-buffer)" t nil)
./gnuplot-20200322.53/gnuplot.el\0136:;;   (global-set-key [(f9)] 'gnuplot-make-buffer)

Then exwm but that should be natural for exwm.

In general, not many. More of them just suggest global bindings in
their comments.

Jean

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

[Gregory Heytings]

>>> Sorry for protracting the conversation, I just think the 
>>> interpretation of the guideline is important.
>>
>> Not for the proposal itself.
>
> Well yes, because if packages may bind to C-c *with* the consent of 
> users, the need for a special package map decreases.
>

As I said, IMO it does not, it can't work as a long-term solution, 26 
letters is simply not enough.  Anyway, neither I nor you can decide what 
the "correct" understanding of that guideline is, so I suggest we stop 
arguing.  A proposal has been made, we'll see what the maintainers do with 
it.

>
> The way I see it is that there is no need for a value like 'best, 
> because this whole idea is that magit wants to bind their keys by 
> default, but it shouldn't bind it to C-c g. If you're going to set 
> magit-define-global-key-bindings to 'best, you might just as well 
> directly bind magit-status to C-c g. I think it would be totally ok for 
> Magit to have the default value set to nil, and then bind to C-c g, but 
> that undermines their entire motivation, as there would be no default 
> binding.
>

Do you use Magit?  Magit binds three commands globally when 
magit-define-global-key-bindings is t (its default value): magit-status to 
C-x g, magit-dispatch to C-x M-g, and magit-file-dispatch to C-c M-g. 
Magit recommends to rebind the last one (magit-file-dispatch) to C-c g, 
and there is no special value for magit-define-global-key-bindings, and no 
code elsewhere in Magit, to do that automatically.

>
> Btw., are there any other examples of packages binding global keys by 
> default?
>

There are indeed (for example Drew's packages), but even if there were 
none, that wouldn't change anything, because there are lots and lots of 
packages that recommend their users to install such global bindings 
manually.

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

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>>> Sorry for protracting the conversation, I just think the
>>>> interpretation of the guideline is important.
>>>
>>> Not for the proposal itself.
>>
>> Well yes, because if packages may bind to C-c *with* the consent of
>> users, the need for a special package map decreases.
>>
>
> As I said, IMO it does not, it can't work as a long-term solution, 26
> letters is simply not enough.  Anyway, neither I nor you can decide
> what the "correct" understanding of that guideline is, so I suggest we
> stop arguing.  A proposal has been made, we'll see what the
> maintainers do with it.

I agree. I was thinking about asking emacs-devel for opinions on the
matter, that will probably make more sense, and might result in a
rephrasing.

>> The way I see it is that there is no need for a value like 'best,
>> because this whole idea is that magit wants to bind their keys by 
>> default, but it shouldn't bind it to C-c g. If you're going to set
>> magit-define-global-key-bindings to 'best, you might just as well 
>> directly bind magit-status to C-c g. I think it would be totally ok
>> for Magit to have the default value set to nil, and then bind to C-c
>> g, but that undermines their entire motivation, as there would be no
>> default binding.
>
> Do you use Magit?  Magit binds three commands globally when
> magit-define-global-key-bindings is t (its default value):
> magit-status to C-x g, magit-dispatch to C-x M-g, and
> magit-file-dispatch to C-c M-g. Magit recommends to rebind the last
> one (magit-file-dispatch) to C-c g, and there is no special value for
> magit-define-global-key-bindings, and no code elsewhere in Magit, to
> do that automatically.

I use MELPA Stable, so my version of Magit is from 2018, so the only one
I use magit-status.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-14 00:19]:
> > > > Sorry for protracting the conversation, I just think the
> > > > interpretation of the guideline is important.
> > > 
> > > Not for the proposal itself.
> > 
> > Well yes, because if packages may bind to C-c *with* the consent of
> > users, the need for a special package map decreases.
> > 
> 
> As I said, IMO it does not, it can't work as a long-term solution, 26
> letters is simply not enough.  Anyway, neither I nor you can decide what the
> "correct" understanding of that guideline is, so I suggest we stop arguing.
> A proposal has been made, we'll see what the maintainers do with it.

C-c a - can be bound to single command

C-c a - can become prefix key for other 54 various commands like 26
        letters plus upper case letters = 52 plus 10 numbers = 62 + 32
        symbols = 94 various commands
C-c a a - can become as well prefix key for 94 various commands
C-c b a - can become as well prefix key for 94 various commands
etc.

It can work as long term solution.

Count all the combinations. It is far far more than 26 combinations. I
find that problem is already solved, just collisions with other key
bindings could be solved by built-in Emacs function where then third
party package invokes the built-in Emacs function to customize the
prefix for the package.

User then decides either to replace some already bound key or to use
some of the free keys. That is why we have programming and computer to
help us decide. Reading comments in packages or READMEs is one way,
but computer assisted decision is smarter way. We can use artificial
intelligence and `key-binding' function as help.

What I wonder is WHY is only one key suggested to be re-purposed? I
cannot see solution there, just more conflicts as then all packages
are going into one key.

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]

Jean Louis <bugs@gnu.support> writes:

> * Gregory Heytings <gregory@heytings.org> [2021-02-14 00:19]:
>> > > > Sorry for protracting the conversation, I just think the
>> > > > interpretation of the guideline is important.
>> > > 
>> > > Not for the proposal itself.
>> > 
>> > Well yes, because if packages may bind to C-c *with* the consent of
>> > users, the need for a special package map decreases.
>> > 
>> 
>> As I said, IMO it does not, it can't work as a long-term solution, 26
>> letters is simply not enough.  Anyway, neither I nor you can decide what the
>> "correct" understanding of that guideline is, so I suggest we stop arguing.
>> A proposal has been made, we'll see what the maintainers do with it.
>
> C-c a - can be bound to single command
>
> C-c a - can become prefix key for other 54 various commands like 26
>         letters plus upper case letters = 52 plus 10 numbers = 62 + 32
>         symbols = 94 various commands
> C-c a a - can become as well prefix key for 94 various commands
> C-c b a - can become as well prefix key for 94 various commands
> etc.
>
> It can work as long term solution.

This would only work, if you insist that packages only bind C-c LETTER
to a map, and not another package, which also only works if the user
doesn't decide to bind C-c LETTER to a command. So I get that there
might not be that many commands, but I'd dare to claim that 52 keys are
a fair number. This is not a matter of computational power or memory,
the needs are not increasing exponentially over time. Keyboards have
stayed more or less the same for over 70 years now and mouses have
rarely more than three buttons. Even with Emacs, I am fairly sure that
if you'd follow what commands and keys most people use, there would be
an uneven/exponential distribution for everyone (while
self-insert-command, yank, switch-to-buffer, ... are more common,
open-line, back-to-indentation, forward/backward-page might differ a lot
more and other commands that are bound by default are probably
completely ignored), that might even be unique (e.g. I've recently
noticed I unconsciously use find-alternate-file as a kind of
revert-buffer).

Maybe it is just me, but it would surprise me if people would keep 52
distinct commands in memory, which all have to be bound globally and are
easy to type. Not insisting on this though.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Jean Louis]

* Philip Kaludercic <philipk@posteo.net> [2021-02-14 02:57]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Gregory Heytings <gregory@heytings.org> [2021-02-14 00:19]:
> >> > > > Sorry for protracting the conversation, I just think the
> >> > > > interpretation of the guideline is important.
> >> > > 
> >> > > Not for the proposal itself.
> >> > 
> >> > Well yes, because if packages may bind to C-c *with* the consent of
> >> > users, the need for a special package map decreases.
> >> > 
> >> 
> >> As I said, IMO it does not, it can't work as a long-term solution, 26
> >> letters is simply not enough.  Anyway, neither I nor you can decide what the
> >> "correct" understanding of that guideline is, so I suggest we stop arguing.
> >> A proposal has been made, we'll see what the maintainers do with it.
> >
> > C-c a - can be bound to single command
> >
> > C-c a - can become prefix key for other 54 various commands like 26
> >         letters plus upper case letters = 52 plus 10 numbers = 62 + 32
> >         symbols = 94 various commands
> > C-c a a - can become as well prefix key for 94 various commands
> > C-c b a - can become as well prefix key for 94 various commands
> > etc.
> >
> > It can work as long term solution.
> 
> This would only work, if you insist that packages only bind C-c LETTER
> to a map, and not another package, which also only works if the user
> doesn't decide to bind C-c LETTER to a command.

Thank you. Here is what I promote:

- packages should not bind globally keys without asking user. When
  user is asked, user has got the control and that is in the spirit of
  free software. In that case any key can be decided by user to be
  bound to package functions.

- I don't say packages should bind C-c keys to anything without asking
  user. By asking user, user gets control and can decide which keys to
  be bound to which functions.

- Yes, I think it is much better to bind C-c LETTER to a map instead
  of binding one key to one function.

- No, don't understand yet the proposal in this subject to "re-purpose
  one key and reserve it for third party packages".

How would that look like? Does that mean for example to re-purpoe C-x
for third party packages so that they do something like:

C-x a - third-party-package-function-1
C-x b - third-party-package-function-2
C-x c - third-party-package-function-3

Is that meant with the proposal?

In that case I find that proposal poor and detrimental. It would break
one of the keys that Emacs was using and break the future for third
party packages as those functions by using one key only, after the
prefix key, would quickly be filled with third party packages.

Instead, I have demonstrated that there are thousands and thousands of
combinations if prefix keys are used. Additionally user can be asked
by artificial intelligence which first prefix key to be used.

In that sense the proposal for third party packages can be easily
solved by the third party package:

- Third party package shall prepare the key map.

- Third party package shall ask the user to choose the prefix to help
  with customization.

- That way third party package is asking user, if user wants, to
  re-purpose one key as prefix for that third party package and helps
  user to customize it.

Problem is solved.

Nothing to be solved on Emacs side.

There was no real problem in the first place.

There was hypothetical problem that was presented without good
analysis.

There are no package authors except of Drew, who asked for "some key"
to be re-purposed for their specific package.

There was no real problem in the first place as there was no
contradictory forces against each other.

Magit's decision to bind package on any key did not show any
contradiction, packages anyway can re-purpose keys without asking
Emacs development team.

But people wish to solve the problem for imaginary package authors who
did not even complain. The one who complained is Drew Adams and his
key bindings were re-purposed for Emacs functions, but not in his
favor. Adverse effect have taken place.

> So I get that there might not be that many commands, but I'd dare to
> claim that 52 keys are a fair number.

Proposal to re-purpose one key for all third party packages is poor
one.

Especially if it is meant NOT to use prefix keys for key maps.

> This is not a matter of computational power or memory, the needs are
> not increasing exponentially over time.

Right now, how it is, and due to convention, many packages will simply
NOT set global key bindings but ask the user to set it. Yesterday I
have done my M-x rgrep on local ~/.emacs.d/elpa and have found that as
the case. I do not have many packages installed, just about 240+ and I
guess that ratio of `global-set-key' continues for the rest of 5000
third party packages.

Situation how it is now, NOT TO RE-PURPOSE ANY KEY for third party
packages would continue with the same non-colliding pattern in the
future. 

If we DO re-purpose one key for third party packages, new convention
is introduced and it would lead to authors deciding to use that ONE
KEY which was re-purposed (which was proposed as one key) and then
among 5000 third party packages authors would be now inclined to
actually start using `global-set-key' because the key for them was
"reserved" and they would quickly (within 1-2 years) come into
collision which does not exist now in reality as practical problem.

> Keyboards have stayed more or less the same for over 70 years now
> and mouses have rarely more than three buttons.

That can change drastically as innovation is developing. Keyboards did
not quite stay more or less the same, obviously we miss some modifier
keys. On about 50% of computers today keyboards completely
disappeared without us, you, people noticing it, those are small
fully featured computers that we call mobile devices. Most of them do
not have physical keyboards, so we cannot say it stayed the same, it
did not.

Engelbart did not introduce just a mouse, there was a chordset with 5
keys that I would find usable even today, but have nowhere to buy it.

Reference:
https://newatlas.com/engelbart-computer-mouse-and-other-innovations/17113/

That keyboard stayed the same is not a benefit, it is
disadvantage. Now is 21st century, 2021, I have expected so much more
from the years 2001 unspoken of 2021 that we still use keyboards. I am
expecting flat surface that may be customized anyhow, by using
lighting where users may reinvent their own keys, where users need not
even click the key, do not even need to type, they would just swing
fingers in the air. We are back behind in time, in under-developed
computing.

On Android/Replicant/Lineage OS devices I have on some keyboards a
possibility to "swipe" keys. I use often 2 mobile phones in the same
time, I use only the left thumb to write things on one phone, the
right thumb writes things on the other phone. Not quite in the same
time, but that is how it may look like to onlooker. That is innovation
that helps and drive speed.

That desktop computer and notebooks still have fragile keyboards
instead of cheaper sensors to track the movements is to me a
a negative surprise of under-development and delay of innovation
implementation.

Reference:
https://www.slideshare.net/01paresh01/keyboards-without-keys-and-boards
https://www.academia.edu/7995378/Virtual_Keyboard_without_keys_and_board

Keyboard layouts in general I find disturbing and old technology taken
from typewriters. It, typewriter layouts, do not need and should not
apply in computing of 21st century. Similarly like swiping on Android
virtual keyboard I could just swipe in the air or touch those by light
appearing letters in the air or touch the completions.

On Android/LineageOS/Replicant, I can use one finger to control Emacs
within Termux, I can send email with one finger only, the thumb, I can
even use pinky if I do not hold the phone in the hand, but on the
notebook or desktop computer I am bothered with whatever modifiers and
key bindings beyond limits, and then we speak of reserving some of
complicated key combinations for future.

Well, there will be no future for keyboards, they will disappear and
new combinations will open that may be so much simpler for users. When
is that going to happen, I don't know, but soon, somewhere between
10-30 years in future. 

> Maybe it is just me, but it would surprise me if people would keep 52
> distinct commands in memory, which all have to be bound globally and are
> easy to type. Not insisting on this though.

I also think that mostly not. Yet some of users mentioned on the
mailing lists to have bound their keys extensively.

That is matter of application and users's demand. Number does not
matter much. On my prefix currently I have bound 15 commands and not
use them all, but I use more M-x commands which I feel I should bind
to the same prefix.

I have 48 various functions that I use frequently locate in the menu
People, and menu WRS for Website Revision System. As menues are nicer
ordered in categories I can easier choose the function that way, but
should by feeling also bind some of those functions to the key
map. About other 80 different functions are related to Hyperscope, the
dynamic knowledge repository and maybe some 10-20 functions I should
have globally bound to the prefix.

I can remember what function does by its meaning but not necessarily
how the function is literally named. For example I know that I can
"Send note by email" to any person in the database and I can remember
that "s m" sends it by email, but I forget that function name is
`hyperscope-send-hyperlink-by-email'.

I have not yet bound all the necessary keys, but I do have to as it
speeds up my work. Using mouse pointer to go into the menu and find
specific menu item takes me few moments more, using a key is
faster. There are other users on mailing list who have bound their
keys and filled a lot of the keys.

Jean

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> There are no package authors except of Drew, who asked for
> "some key" to be re-purposed for their specific package.

???

Everyone here who ever wrote more than 100 posts here is
a package author, almost. Here are my 8. (Should perhaps be
modernized, some of them.)

  https://dataswamp.org/~incal/emacs-packs/

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 09:34]:
> Jean Louis wrote:
> 
> > There are no package authors except of Drew, who asked for
> > "some key" to be re-purposed for their specific package.
> 
> ???
> 
> Everyone here who ever wrote more than 100 posts here is
> a package author, almost. Here are my 8. (Should perhaps be
> modernized, some of them.)
> 
>   https://dataswamp.org/~incal/emacs-packs/

Sure, but did you ask for re-purposiation?

Do your packages have need for global-set-key?

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Gregory Heytings]

>
> So I get that there might not be that many commands, but I'd dare to 
> claim that 52 keys are a fair number. This is not a matter of 
> computational power or memory, the needs are not increasing 
> exponentially over time.
>
> [...]
>
> Maybe it is just me, but it would surprise me if people would keep 52 
> distinct commands in memory, which all have to be bound globally and are 
> easy to type. Not insisting on this though.
>

On Elpa and Melpa there are currently 5121 distinct packages.  And there 
are lots of packages that are not on Elpa and/or Melpa.  That number can 
only grow over time, perhaps not exponentially, but grow nonetheless. 
Emacs itself has lots and lots of commands bound to keys, I don't know the 
exact number, but it's surely an order of magniture larger than 52. 
"Starter kits" such as Spacemacs include 100 or more external packages. 
Or course not all of them would have a reason to bind command globally, 
but some will bind more than one command.  So it seems to me that the 52 
keys limit is easy to reach.

I agree with Drew that the solution you propose is not user-friendly, 
because querying a user who doesn't yet know how a package works and what 
its commands are to bind some commands they do not yet know to a key is 
confusing.  What users would most likely do is to answer "yes" everywhere 
without thinking further.  (It reminds me what Windows program installers 
did when I started using computers, about 25 years ago.  They asked you a 
few questions, I don't remember precisely what they were, but it was 
something like "where do you want to install the program?", "do you want 
to put a shortcut on the desktop?", "do you want to put a shortcut in the 
start menu?".  You read those questions when you installed your first 
program, because you thought they were important, but later you just 
clicked "yes" to every question.)

libraries (was: Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Gregory Heytings wrote:

> On Elpa and Melpa there are currently 5121 distinct packages [...]

We could reduce the code size a lot if we did huge package
libraries and organized everything systematically, with search
tools and stuff, optimally...

Below is just some Elisp that comes to mind. How many people
did that, in how many different but similar versions and
varieties, instead of getting it somewhere?

I still don't know where to look and installation is more
difficult than writing it even if I were to find it.

Bring all simple things into a bunch of huge files, done deal.

(defun // (n d)
  (/ n d 1.0) )
;; (// 8 256) ; 0.03125
;; (/  8 256) ; 0

(defun percent (n d)
  (let ((pct (/ n d 0.01)))
    (message "%.1f%%" pct)))
;; (percent 8  256) ; 3.1%
;; (percent 0 1337) ; 0.0%

(defun mean-value (vs)
  (let*((sum  (apply #'+ vs))
        (mean (/ sum (length vs) 1.0)) )
    mean) )

(defun hypotenuse (c1 c2)
  (sqrt (+ (* c1 c1) (* c2 c2))) )

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 2583 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> So I get that there might not be that many commands, but I'd dare to
>> claim that 52 keys are a fair number. This is not a matter of 
>> computational power or memory, the needs are not increasing
>> exponentially over time.
>>
>> [...]
>>
>> Maybe it is just me, but it would surprise me if people would keep
>> 52 distinct commands in memory, which all have to be bound globally
>> and are easy to type. Not insisting on this though.
>
> On Elpa and Melpa there are currently 5121 distinct packages.  And
> there are lots of packages that are not on Elpa and/or Melpa.  That
> number can only grow over time, perhaps not exponentially, but grow
> nonetheless. Emacs itself has lots and lots of commands bound to keys,
> I don't know the exact number, but it's surely an order of magniture
> larger than 52. "Starter kits" such as Spacemacs include 100 or more
> external packages. Or course not all of them would have a reason to
> bind command globally, but some will bind more than one command.  So
> it seems to me that the 52 keys limit is easy to reach.

I'm not sure that the number of published packages necessarily means
that 1. user install more packages over time 2. some fixed proportion of
these require global bindings. More often than not, packages might just
provide hooks or implement interfaces like Xref or CAPF, thus avoiding
their own special keys.

> I agree with Drew that the solution you propose is not user-friendly,
> because querying a user who doesn't yet know how a package works and
> what its commands are to bind some commands they do not yet know to a
> key is confusing.  What users would most likely do is to answer "yes"
> everywhere without thinking further.  (It reminds me what Windows
> program installers did when I started using computers, about 25 years
> ago.  They asked you a few questions, I don't remember precisely what
> they were, but it was something like "where do you want to install the
> program?", "do you want to put a shortcut on the desktop?", "do you
> want to put a shortcut in the start menu?".  You read those questions
> when you installed your first program, because you thought they were
> important, but later you just clicked "yes" to every question.)

That is why ideally each suggestion should be accompanied by an
explanation, and keep the number of suggestions to a minimum. But this
can be discussed when I come around to actually implementing the idea,
and sending it to emacs-devel.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

RE: [External] : Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Drew Adams]

(I haven't read all of your long message here.
And I wouldn't have bothered to reply to it,
if I hadn't noticed that you mention me in
passing, and you did so inaccurately.)
___

> There are no package authors except of Drew, who
> asked for "some key" to be re-purposed for their
> specific package.

No, I never, ever, asked for any Emacs keys to
be repurposed for any of my libraries.

I asked that keys that were _not_ yet bound by
Emacs by default, continue to NOT be bound by
Emacs by default.  That's all.  No repurposing
- for my benefit or for any other reason.

Before that general request, I asked that the
unbound (by default) prefix key `C-x p' NOT
suddenly be bound by Emacs by default.  To no
avail - my polite plea was ignored.

I later asked that the unbound (by default)
key `C-x x' NOT be bound by Emacs by default.
To no avail - my plea was ignored.

It was only recently that I asked more generally
that (barring discussion followed by exceptional
maintainer decision) _NO_ new keys be bound by
Emacs by default - we should have a moratorium
on doing that.  To no avail, so far.

> There was no real problem in the first place as
> there was no contradictory forces against each other.

Not sure what you're referring to, but there is
a very real problem of Emacs binding more and
more keys by default - the set of keys still
unbound by default is dwindling to extinction.

This is not a problem for _users_.  At least not
directly.  Users can always bind any keys they
like.  It's a problem for 3rd-party code (and
thus indirectly for its users).  There need be
no discussion about what users can do - they
are welcome to do anything, and the conventions
explicitly say so.

> packages anyway can re-purpose keys without asking
> Emacs development team.

Sure, 3rd-party code _can_ do anything, without
regard to anyone else.  We're talking about GNU
Emacs key-binding _conventions_: rules for
playing well together.

It's much more constraining on 3rd-party code
when Emacs itself binds a key by default, than
when some other 3rd-party code binds the same
key by default.  This has all been explained,
with good arguments.  No one has argued to the
contrary.  When Emacs itself does something
like that, it changes the game for everyone.

It's not helpful for people here to simply
ignore the discussion that's taken place (in
emacs-devel and bug threads), and instead add
repetition of Q&A and arguments.  Please read
the discussion, so arguments aren't repeated
here needlessly, wasting everyone's time and
energy.

(That is, do that if you're really interested
in the question/problem.  If you're not, then
don't bother.  But please don't just repeat
questions or arguments here that have already
been made in the more general discussion.)

Again, it's not I who spread this discussion
from bug threads to emacs-devel, or to this
user help list.

Raising the discussion on emacs-devel was a
_good_ thing.  But there's little sense in
ignoring what's already been said, and
starting over again here.  Everyone's welcome
to add their voice in any way to the existing
discussion.  But please _add_, cognizant of
what's already been said.

> But people wish to solve the problem for
> imaginary package authors who did not even
> complain. The one who complained is Drew Adams

Actually, several people have argued that the
problem exists.  You seem to be ignoring the
general discussion and just imagining things.

I was the one who brought up the problem, yes.
But I brought it up in the context of bug
discussions where new default key-binding
actions were being discussed.  Yes, I objected
to those proposed actions.

Had the initial grabbing of a prefix key for
Project chosen a key that I wasn't already
using for (many) Bookmark+ commands, it's
unlikely I would have said anything.

I spoke up then because that change affected
me and users of my library directly.  I asked
politely that they choose some other prefix
key to grab for Project.  My request was
rejected summarily, just because my code is
3rd-party.

Or perhaps because the request was from me
(?) - the reason given was just that Emacs
dev is under no "obligation" to respect
such a request, which is of course true
and uncontested - no obligation.  But some
consideration would have been nice.

It was not even I who took the discussion
from bug threads to emacs-devel.  So no,
I'm not the only person who recognizes the
problem.

> Right now, how it is, and due to convention,
> many packages will simply NOT set global key
> bindings but ask the user to set it.

This is a false dichotomy.  Use of any 3rd
party code is optional.  No one's forced to
load any library.  Everyone agrees that in
general, when it makes sense, it's more
polite for just loading a library not to
change Emacs session state (beyond loading
definitions etc.).

But there are all kinds of 3rd-party code.
There's little real difference between adding
a keymap & providing a command to activate it,
and just activating it by default, provided
doc or commentary makes clear what happens.

I have code that does one and code that does
the other.  And I have code that just suggests
key bindings, in comments.  In general, more
important and larger libraries, with more
users, need to be handled more carefully. 

It's important to understand the reasons
behind any convention - the context and
scope for its action.

Consider, for example, the convention that
functions (including commands) shouldn't
change or bind user option values.

Emacs itself provides functions and commands
that do just that.  Otherwise there would be
no way to do it!

Does that (good, reasonable) convention mean
that 3rd-party code should never provide
commands, menus, UI's, etc. that users can
use to change option values, face values,
etc.?  Of course not.

And yes, I have code that provides such
UI's, e.g., code that lets you tweak face
values incrementally, showing the effect
as you do so.  And I have code that helps
improve the Customize UI.

There's no rule against improving Emacs by
offering such things - that would be absurd.
(And the conventions apply to Emacs's own
code also, not just to 3rd-party code.)

That convention is only a general guideline,
which points out that it makes no sense, and
it can be impolite, usually, for 3rd-party
code to change preferences that a user has
set.  But such a rule clearly doesn't apply
to code whose very purpose is to help a
use choose and set such preferences.

This _should_ be obvious.  But even Emacs
developers (misguidedly, IMO) shy away from
_binding_ user options within a function,
even if the purpose of the function involves
temporarily using a different value.  To me
that's misunderstanding, taking the guideline
as a hard-&-fast rule, and not understanding
the logic behind it.

RE: [External] : Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Drew Adams]

> I agree with Drew that the solution you propose is not user-friendly,

Huh?  AFAIK, I've said nothing about what you guys
seem to be talking about now.  Please cite what
you think I said about this, if you're going to
make references to what I've said.

Perhaps you're confusing me with someone else,
wrt this point?  There are so many messages, and
the subject seems to careen wildly without the
Subject line changing, that I, at least, have
trouble following (especially since much of
what's said doesn't hold much interest for me).

> because querying a user who doesn't yet know how
> a package works and what its commands are to bind
> some commands they do not yet know to a key is
> confusing.

That's true, in general, though a query/prompt
can make things clear.  It can even pop up doc
etc. to make things clear.  I'm not saying
anything about how appropriate such querying
might be.  It might be inefficient, inappropriate,
or even downright annoying.

I, for one, think that users are well served
by taking the initiative to read something
about a package, command, or whatever before
starting to load or use it.  That's just my
advice.

In the "old days" user read the Commentary in
a library before using it.  And wise users even
looked at the code, at least as a sanity check.

Nowadays, I get the impression that many users
just load a package and give it a try, with no
regard to help/doc the author has provided, and
no concern or curiosity about the code (what it
does, how it does it, security, etc.).

> What users would most likely do is to answer
> "yes" everywhere without thinking further.

Yup.  Laziness, mostly, I guess.  Or blind
faith, perhaps.

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Gregory Heytings]

>> I agree with Drew that the solution you propose is not user-friendly,
>
> Huh?  AFAIK, I've said nothing about what you guys seem to be talking 
> about now.  Please cite what you think I said about this, if you're 
> going to make references to what I've said.
>

See:

Date: Sat, 13 Feb 2021 20:48:11 +0000
Message-ID: <SA2PR10MB4474A5DC64E0BF9FCF3C44D6F38A9@SA2PR10MB4474.namprd10.prod.outlook.com>

in which you said:

>> Philip Kaludercic suggested some code for prompting users before 
>> mapping keys.  I think that's a good idea.
>
> Maybe that could be part of a solution.  But many users will not 
> appreciate, or not be prepared for, making such key-binding decisions at 
> the outset and on the fly.
>

Re: [External] : Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Jean Louis]

Maybe Emacs itself could have detection for a package that needs a
prefix, something like:

(need-prefix-key 'my-key-map) where `need-prefix-key' is the future
imaginary Emacs built-in function.

and then Emacs can on first invocation of the package function ask
user: This package requires a prefix key, please press some of the
keys like C-c and some letter or Super and some letter to choose
it. It could tell user that key is already bound and if user is unsure
or not.

User could also customize the option `ask-me-for-prefix-keys' if user
wish to be asked for those prefix keys.

That would be very hand solution, no package would need to set a key
globally, just make a map, and Emacs itself would be notified by the
package that package needs a prefix key. Emacs would then ask user for
prefix key if user has set the variable `ask-me-for-prefix-key'.

That solves the whole problem for many third party packages.

* Drew Adams <drew.adams@oracle.com> [2021-02-14 21:31]:
> (I haven't read all of your long message here.
> And I wouldn't have bothered to reply to it,
> if I hadn't noticed that you mention me in
> passing, and you did so inaccurately.)
> ___
> 
> > There are no package authors except of Drew, who
> > asked for "some key" to be re-purposed for their
> > specific package.
> 
> No, I never, ever, asked for any Emacs keys to
> be repurposed for any of my libraries.
> 
> I asked that keys that were _not_ yet bound by
> Emacs by default, continue to NOT be bound by
> Emacs by default.  That's all.  No repurposing
> - for my benefit or for any other reason.

Yes, that is what I meant despite inaccurate description.

> Not sure what you're referring to, but there is
> a very real problem of Emacs binding more and
> more keys by default - the set of keys still
> unbound by default is dwindling to extinction.

I understand your opinion but contrary to it, I found there are many
available key bindings, we mentioned here Super key, key prefixes or
maps, so it amounts in thousands. Keyboard will die sooner as physical
keyboard then the available key bindings.

> This is not a problem for _users_.  At least not
> directly.  Users can always bind any keys they
> like.  It's a problem for 3rd-party code (and
> thus indirectly for its users).  There need be
> no discussion about what users can do - they
> are welcome to do anything, and the conventions
> explicitly say so.

Even third parties are welcome to do anything.

What repercussion is there for third party if they actually break the
convention? Maybe such package would not be accepted in ELPA, but that
is about all. They are free to bind as they wish. But they don't and
follow the convention.

I have not found real conflict, like nobody said so far (that I have
spotted) that some key bindings seriously conflict with something
else. It is hypothetical problem, but not practical.

> It's not helpful for people here to simply
> ignore the discussion that's taken place (in
> emacs-devel and bug threads), and instead add
> repetition of Q&A and arguments.  Please read
> the discussion, so arguments aren't repeated
> here needlessly, wasting everyone's time and
> energy.

Maybe not. First one has to list the real problem, practical specific
problem. Let us solve that.

Put hypothetical problems on side, just disregard them. Recursive grep
in few thousands of MELPA packages has shown that almost none of them
binds C-c LETTER by default, there are those binding other keys by
default. But none of people complained.

Why reserve anything, if there is neither practical problem at hand to
be solved, neither almost none person to say I NEED THIS KEY X FOR
PACKAGE Y. One person I know is you that you need it, and your request
was ignored, I have not seen explanation why and how.

anx-api package:

(if anx-use-global-keybindings
    (progn
      (global-set-key (kbd "C-x C-a A") 'anx-authenticate)
      (global-set-key (kbd "C-x C-a a") 'anx-get-user-authentication-credentials)
      (global-set-key (kbd "C-x C-a S") 'anx-switch-users)

pager-default-keybindings has some defaults set. Logical by name.

seethru package recommends some keyboards through a function, does not
bind by default (I guess).

cssh package bind C-= and C-M-=

move-text package has function to bind some keys

cycbuf package as well

better-defaults has some global bindings, logical to its purpose.

From 2400+ packages the above shows that there are no conflicts so
far. Majority of packages recommend bindings to user to make it by
their own will.

So which real world, practical conflict is there at hand to be solved?

I would not say discussion is useless and that people have to follow
arguments carefully especially as we talk about key bindings that
practically do not affect users, nor cause problems.

> (That is, do that if you're really interested
> in the question/problem.  If you're not, then
> don't bother.

I have asked already before few days, what is the practical, specific,
real world problem to be solved? I do not see any after the analysis
of the discussion. I know your case, OK and I know you will find
solution to it. But you have not started discussion, you are proposing
constructive things.

Nevertheless, I see no real world problem.

I see hypothetical problems.

> But please don't just repeat questions or arguments here that have
> already been made in the more general discussion.)

I may mention, I am not a database that collects each piece of details
ever mentioned on all mailing lists and excludes those that have been
mentioned. That is life.

> > But people wish to solve the problem for
> > imaginary package authors who did not even
> > complain. The one who complained is Drew Adams
> 
> Actually, several people have argued that the
> problem exists.  You seem to be ignoring the
> general discussion and just imagining things.

If problem exist, then which real world problem is it?

Is it hypothetical problem with imaginary future packages?

Short analysis has shown that packages do not even bind keys, they
just recommend key bindings. That is the solution that existed before
and exists now. There is proposal that it may become little more
sensitive, program could recommend bindings by detecting which keys
are bound to what and let user just type or choose a new key for new
functions instead of advising users in the README or comment section.

So if packages do not bind keys by large, where is the real problem?

With "real problem" let us know the package name that bound some keys
and where it conflict with some other key, or where package author
does not have a solution to make package functional for the user.

> I spoke up then because that change affected
> me and users of my library directly.  I asked
> politely that they choose some other prefix
> key to grab for Project.  My request was
> rejected summarily, just because my code is
> 3rd-party.

That I have seen, it does not look nice. Did you solve the problem?

You can make a function that asks user on which key user wish to put a
prefix key. That would be solved with it. No need to dwell with
global-set-key, just let users decide themselves.

1. Press your preferred prefix key for this package

2. That key you have chosen is bound to `this-other-function', are you
   sure you wish to re-purpose the key for this package?

3. If no, press other prefix key and try again.

4. If yes, you may again customize the prefix key by invoking function
   "my-package-customize-prefix"

It should be that simple. Or do it as majority to advise user to set
bindings as they wish in the comments section.

Majority of packages do not bind keys for packages. That is simple
solution.

Package invocation like first time running of a function could detect
if a key has been defined as prefix and run the wizard to customize
the global prefix key. Some packages show that they have similar
functions, not really wizardry, but there are similar functions where
user invokes a function and package binds global keys.

Packages define various keys and let user make the prime decision. I
have seen with M-x rgrep that packages do similar to that.

This comes from anx-api package:

- it looks like if user defined `anx-use-global-keybindings' that it
  would automatically set some global keys.

(if anx-use-global-keybindings
    (progn
      (global-set-key (kbd "C-x C-a A") 'anx-authenticate)
      (global-set-key (kbd "C-x C-a a") 'anx-get-user-authentication-credentials)
      (global-set-key (kbd "C-x C-a S") 'anx-switch-users)

but they will mostly suggest to users to use some of C-c combinations
in the comment section. I think that is old fashioned and that wizard
functions should do that work.

Jean

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-14 21:58]:
> 
> > > I agree with Drew that the solution you propose is not user-friendly,
> > 
> > Huh?  AFAIK, I've said nothing about what you guys seem to be talking
> > about now.  Please cite what you think I said about this, if you're
> > going to make references to what I've said.
> > 
> 
> See:
> 
> Date: Sat, 13 Feb 2021 20:48:11 +0000
> Message-ID: <SA2PR10MB4474A5DC64E0BF9FCF3C44D6F38A9@SA2PR10MB4474.namprd10.prod.outlook.com>
> 
> in which you said:
> 
> > > Philip Kaludercic suggested some code for prompting users before
> > > mapping keys.  I think that's a good idea.
> > 
> > Maybe that could be part of a solution.  But many users will not
> > appreciate, or not be prepared for, making such key-binding decisions at
> > the outset and on the fly.

It can be easily solved by introducing variable
`ask-me-for-packages-which-need-prefix-key' which is by default NIL.

Packages can then notify Emacs that they need one or more prefix keys:

(need-prefix-key 'my-package-map-1)
(need-prefix-key 'my-package-map-2)

Emacs would then provide the unified wizard function that asks those
users who have set the above variable for prefix keys for the package.

That solves universally those hypothetical problems discussed.

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> It can be easily solved by introducing variable
> `ask-me-for-packages-which-need-prefix-key' which is by
> default NIL.
>
> Packages can then notify Emacs that they need one or more
> prefix keys:
>
> (need-prefix-key 'my-package-map-1)
> (need-prefix-key 'my-package-map-2)
>
> Emacs would then provide the unified wizard function that
> asks those users who have set the above variable for prefix
> keys for the package.
>
> That solves universally those hypothetical
> problems discussed.

A hypothetical solution - to solve a hypothetical problem.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: [External] : Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> Maybe Emacs itself could have detection for a package that
> needs a prefix, something like:
>
> (need-prefix-key 'my-key-map) where `need-prefix-key' is the
> future imaginary Emacs built-in function.

And even more so, as that would imply quite possibly million,
maybe billion imaginary functions!

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Gregory Heytings]

>
> I'm not sure that the number of published packages necessarily means 
> that 1. user install more packages over time 2. some fixed proportion of 
> these require global bindings. More often than not, packages might just 
> provide hooks or implement interfaces like Xref or CAPF, thus avoiding 
> their own special keys.
>

Frankly, I don't understand why it is necessary to argue so much to 
explain that a limit of 26 or 52 global bindings is not enough.  It's as 
if your operating system forced you to have at most 26 or 52 files or 
folders in each folder; of course it would be feasible to use such an 
operating system, but it would be terribly impractical.  I see that, out 
of the ~11K commands in Emacs core, there are currently ~450-500 commands 
bound to keys in global-map (counting only the C-something, M-something 
and C-M-something).  I or you may, today, not need more than 26 or 52 
global bindings for external packages, we may perhaps only need 10 or 20, 
but this discussion isn't about me or you, or about the current situation, 
it's about finding a long-term solution to a problem, with the hope that 
in the long term more and more external packages will be useful to a large 
audience.  It's about making Emacs friendlier for beginners, and also for 
third-party library developers by giving them a "home" in Emacs' default 
keyboard bindings.

RE: [External] : Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Drew Adams]

> >> I agree with Drew that the solution you propose is not user-
> friendly,
> >
> > Huh?  AFAIK, I've said nothing about what you guys seem to be talking
> > about now.  Please cite what you think I said about this, if you're
> > going to make references to what I've said.
> 
> See:
> Date: Sat, 13 Feb 2021 20:48:11 +0000
> Message-ID:
> <SA2PR10MB4474A5DC64E0BF9FCF3C44D6F38A9@SA2PR10MB4474.namprd10.prod.out
> look.com>

Please provide a URL next time.  I don't know how
(or care to know how) to find the message using
such an incantation.

> in which you said:
> 
> >> Philip Kaludercic suggested some code for prompting users before
> >> mapping keys.  I think that's a good idea.
> >
> > Maybe that could be part of a solution.  But many users will not
> > appreciate, or not be prepared for, making such key-binding decisions
> > at the outset and on the fly.

Guilty as charged, I guess (haven't seen the context).

But I don't say that that is "not user-friendly".
I was saying that as it was presented it has
limited appeal - it might be made _part_ of a
workable solution; dunno.

RE: [External] : Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Drew Adams]

> > Not sure what you're referring to, but there is
> > a very real problem of Emacs binding more and
> > more keys by default - the set of keys still
> > unbound by default is dwindling to extinction.
> 
> I understand your opinion but contrary to it, I found there are many
> available key bindings, we mentioned here Super key, key prefixes or
> maps, so it amounts in thousands. Keyboard will die sooner as physical
> keyboard then the available key bindings.

I disagree.

> > [Users] are welcome to do anything, and the
> > conventions explicitly say so.
> 
> Even third parties are welcome to do anything.

No.  The conventions reserve some keys for users,
some keys for major modes, and some keys for
minor modes.  "Reserved" means that if you follow
the convention then you don't use those, except
as a user, or for a major mode, or for a minor mode.

> What repercussion is there for third party if they actually break the
> convention?

If you don't play well with the others in the sand
box you might find yourself on the receiving end.

The conventions are there as guidelines to good,
social behavior.  No, there is no key-binding
Gestapo that will grab you out of your bed and
haul you away.  So what?

> Maybe such package would not be accepted in ELPA, but that
> is about all. They are free to bind as they wish. But they don't and
> follow the convention.

You do that, if you like.  I don't.

You can get away with driving at 230 km/hr on a
highway in France - they have limited real traffic
control.  That doesn't make such behavior smart or
civilized.

> I have not found real conflict, like nobody said so far (that I have
> spotted) that some key bindings seriously conflict with something
> else. It is hypothetical problem, but not practical.

No, key-binding conflicts, just like name conflicts,
are a practical problem.  That's why we have key
binding conventions, to avoid conflicts.

For names, Elisp at least has the possibility of
using additional obarrys.  But that's quite limited,
in practice.  Common Lisp has its "packages", which
are a bit like XML namespaces.  For key bindings
Elisp has only polite conventions.  And those work
well enough, in practice.  (They can't deal with an
Emacs that is fast developing the remaining free
territory, however.)

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Emanuel Berg via Users list for the GNU Emacs text editor]

Gregory Heytings wrote:

> Frankly, I don't understand why it is necessary to argue so
> much [...]

Absolutely positively, it isn't necessary by any means.
The only reason to do it is if you enjoy it.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: [External] : Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>> I understand your opinion but contrary to it, I found there
>> are many available key bindings, we mentioned here Super
>> key, key prefixes or maps, so it amounts in thousands.
>> Keyboard will die sooner as physical keyboard then the
>> available key bindings.
>
> I disagree.

I don't know if I disagree or agree, but note that it isn't
just a matter of the number of theoretical keybindings, it is
also what keybindings are ergonomic, short, close to asdf jkl;
(i.e. fast) perhaps mnemonic (tho that shouldn't be
over-emphasized, particularly not for stuff that is used
often, as that will bypass the brain pretty soon anyway and
enter muscle memory) and such concerns.

Good keybindings are not infinite.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Robert Thorpe]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> I'm not sure that the number of published packages necessarily means 
>> that 1. user install more packages over time 2. some fixed proportion of 
>> these require global bindings. More often than not, packages might just 
>> provide hooks or implement interfaces like Xref or CAPF, thus avoiding 
>> their own special keys.
>>
>
> Frankly, I don't understand why it is necessary to argue so much to 
> explain that a limit of 26 or 52 global bindings is not enough.  It's as 
> if your operating system forced you to have at most 26 or 52 files or 
> folders in each folder; of course it would be feasible to use such an 
> operating system, but it would be terribly impractical.  I see that, out 
> of the ~11K commands in Emacs core, there are currently ~450-500 commands 
> bound to keys in global-map (counting only the C-something, M-something 
> and C-M-something).  I or you may, today, not need more than 26 or 52 
> global bindings for external packages, we may perhaps only need 10 or 20, 
> but this discussion isn't about me or you, or about the current situation, 
> it's about finding a long-term solution to a problem, with the hope that 
> in the long term more and more external packages will be useful to a large 
> audience.  It's about making Emacs friendlier for beginners, and also for 
> third-party library developers by giving them a "home" in Emacs' default 
> keyboard bindings.

I'm not sure I understand your point here.  Any single key that's picked
will have a similar limitation.

For example, let's suppose that M-o is picked.  That's my favourite, I
know you don't like it.  In that case any key can follow it.  That gives
the entire keyboard, maybe 100 keys.  Is that so different to 52?

Also, nested prefix keys can be used.  For example suppose that Magit
uses C-c g as a prefix.  It can then be followed by any keyboard
character.

However, I agree with you that adding things to the users space in the
C-c prefix is not ideal.  Adding another prefix key for 3rd-parties
would be better.  Assuming, of-course, that Drew Adam's proposal of a
moratorium is off-the-table.

BR,
Robert Thorpe

Re: [External] : Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2021-02-15 02:30]:
> > Maybe such package would not be accepted in ELPA, but that
> > is about all. They are free to bind as they wish. But they don't and
> > follow the convention.
> 
> You do that, if you like.  I don't.

I have not written that above sentence correctly. What I wanted to say
is that third party packages do not break the convention and mostly
how I have shortly analyzed it, do not set globally keys.

They mostly will advise users to set global keys.

While they are free, they don't do that.

> > I have not found real conflict, like nobody said so far (that I have
> > spotted) that some key bindings seriously conflict with something
> > else. It is hypothetical problem, but not practical.
> 
> No, key-binding conflicts, just like name conflicts,
> are a practical problem.  That's why we have key
> binding conventions, to avoid conflicts.

OK and where is the actual problem?

Can we define it?

I can see that some packages would recommend same key bindings on
conflicting keys, but that is not necessarily a problem, because there
are no people telling that they have conflict with it.

Conflicting keys are not necessarily conflict for the person.

For example can you tell me which key from which package collides with
other key in other package AND that it becomes a problem or conflict?

Person complaining please stand up.

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Gregory Heytings]

>
> I'm not sure I understand your point here.  Any single key that's picked 
> will have a similar limitation.
>

With a single key you indeed have a limitation, but it's the limitation of 
the keyboard, not an arbirary one.  You have full access to all letters, 
all digits, all symbols, combined or not with the control and/or meta 
modifier.  That's a lot more than 26 or 52 keys.

>
> For example, let's suppose that M-o is picked.  That's my favourite, I 
> know you don't like it.
>

It's in the proposal, it would be a perfect choice, together with C-o.

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

[Gregory Heytings]

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

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

[Dmitry Gutov]

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.

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Robert Thorpe]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> I'm not sure I understand your point here.  Any single key that's picked 
>> will have a similar limitation.
>>
>
> With a single key you indeed have a limitation, but it's the limitation of 
> the keyboard, not an arbirary one.  You have full access to all letters, 
> all digits, all symbols, combined or not with the control and/or meta 
> modifier.  That's a lot more than 26 or 52 keys.

I see what you mean but I don't think it's a huge difference.  Most
desktop keyboards have ~104 keys.  And some of those can't be
differentiated from each other by Emacs.  Laptop keyboards usually have
fewer, mine has 81.

>> For example, let's suppose that M-o is picked.  That's my favourite, I 
>> know you don't like it.
>>
>
> It's in the proposal, it would be a perfect choice, together with C-o.

I think C-o is a terrible idea.  Open-line is a very useful command.
It's useful in all sorts of text editing scenarios.  Yes, the same can
be done using return and C-b, but that's longer.

In my opinion, M-o is a good idea though.  The M-o prefix is only really
useful in enriched mode.  Perhaps it could be retained in that mode
only.

BR,
Robert Thorpe

Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Gregory Heytings]

>>> I'm not sure I understand your point here.  Any single key that's 
>>> picked will have a similar limitation.
>>
>> With a single key you indeed have a limitation, but it's the limitation 
>> of the keyboard, not an arbirary one.  You have full access to all 
>> letters, all digits, all symbols, combined or not with the control 
>> and/or meta modifier.  That's a lot more than 26 or 52 keys.
>
> I see what you mean but I don't think it's a huge difference.  Most 
> desktop keyboards have ~104 keys.  And some of those can't be 
> differentiated from each other by Emacs.  Laptop keyboards usually have 
> fewer, mine has 81.
>

Indeed, and when you combine these with the control and/or meta and/or 
shift modifier you have ~400 possible keys.  Which means that with two 
prefix keys you have ~800 possible keys.

The main point is that third-party packages are first-class citizens and 
should get all possible keys, not an arbitrary subset.

>>> For example, let's suppose that M-o is picked.  That's my favourite, I 
>>> know you don't like it.
>>
>> It's in the proposal, it would be a perfect choice, together with C-o.
>
> I think C-o is a terrible idea.  Open-line is a very useful command.
>

The proposal explicitly mentions that open-line would remain bound to C-o 
C-o.  That's three key presses instead of two.  And if you think that 
open-line is so important in your workflow that pressing three keys 
instead of two is really not possible, you can of course always bind 
open-line to C-o in your init file, and move the third-party library 
keymap that would be on C-o somewhere else.