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

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

[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

[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

[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

"Windows" key [was: Repurpose one key and reserve it for third-party] packages

[tomas]

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

On Tue, Feb 09, 2021 at 01:05:22AM +0100, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> Francis Belliveau wrote:
> 
> > I vote against the removal of the current C-o functionality.
> > I would not want to use two keystrokes where I currently use
> > only one. [...]
> 
> What about the Windows key, should we keep that or remove that
> as well?

In my setup, the Windows key is bound to... window manager commands
(well, duh ;-)

I still don't know what to do with its right symmetrical sister
(labelled "print", but my evil plan is to turn it into a modifier,
too). I thought it'd reserved for Emacs, but I still hesitate to
open up one more key dumpster. So I'm still pondering :-)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[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

[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

[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: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

> > The current key binding conventions (see `(elisp) Key Binding
> > Conventions') reserve keys for users, for major modes and for
> > minor modes, but not for third-party packages.
> 
> In my understanding those third party packages usually define major or
> minor modes so the reservation of keys for third party packages is
> thus already supported that way.

The question is about reserving keys for 3rd-party
code so that _Emacs itself_ doesn't bind them by
default.  It's one thing for a 3rd-party library
to possibly conflict with another such.  It's a
different thing if Emacs suddenly binds keys by
default that the library has bound.

And no, there's no limitation that 3rd-party code
bind keys only in major- or minor-mode keymaps.

In general, it's more polite for 3rd-party code
not to bind global keys by default.  But it can,
and it sometimes does.  Use of a 3rd-party is
optional, just as turning on a major or minor
mode is optional.

> So I think there is no need to reserve more keys for third party
> packages. Finally, keys are limited.

The question is not about reserving keys
for 3rd-party use _from users_.  It's about
reserving them from Emacs itself, i.e., so
they don't become new _default_ bindings.

(And it can't be about reserving "more" keys
for 3rd-party code, as _NO_ keys are reserved
for them so far.)

There is no question about not allowing
_users_ to bind some keys.  Users can bind
or unbind ANY keys.  Always.

> many Emacs Lisp programmers became such due to fiddling with their
> configurations in the first place. That is positive impact, not a
> negative impact.

100%, yes.  (And maybe all, not just many.)

> > Reserving one key for third-party packages solves the above problems:

(No, it doesn't.)

> > third-party packages can automatically bind a few keys in that
> > reserved area, without conflicting with keys reserved for users and without
> > conflicting with future Emacs evolutions.
> 
> There are more than one keys reserved already in the manner you
> described such as those reserved for users can be proposed and used by
> third party packages, including those for minor and major modes, they
> can be used by third party packages. Solution is just there.

There are currently NO keys reserved for 3rd-party
code, so that Emacs itself won't bind them by default.

There is no question of reserving any keys from
users, so they can't use them.  Never has been,
never will be.

FWIW, I disagree with Gregory's proposal, which
is a scaled-down version of my proposal, which
is to reserve _ALL_ keys currently not bound by
default, for 3rd-parties to use.  He proposes to
reserve only one key for that.

IOW, I proposed that Emacs keep its mitts off
the few remaining top-level keys (which includes
top-level prefix keys).  We should at least have
a _moratorium_ on such grabbing by Emacs.

Gregory's reduction of my proposal is to reserve
only _one_ top-level key for 3rd-party use.
Emacs itself would be free to bind all the
remaining keys by default.  I oppose that, even
if someone will say that one is better than none.

> Reserving key for third party packages sounds limiting to me.
> They may have different preference than just one key.

Yes.  There are good reasons for any party: Emacs
itself, a 3rd-party, or a user, to want to use
any particular top-level key, including using it
as a prefix key.

> Recently I have learned how to define the prefix command...
> In my opinion that is great way of defining keys for third party
> packages. They could define the full key bindings list and let the
> user decide on the prefix key. They could propose some prefix key.
> It is one line in the configuration. It is something like:
> 
> (global-set-key (kbd "s-p") 'cf-map)

Exactly.  The binding can be optional (e.g. by
command or user option).  Or it can be provided
by default.

A user can easily move the whole set of keys on
that prefix key to another prefix key - or move
some, or none.

Grouping keys on a keymap is a great way to make
them available as a set.  And sometimes it makes
sense for a library to provide more than one set.

> which one do you like to use as prefix key for this third party
> package?
> Some question as above could help users quickly decide on a prefix and
> the line could be automatically inserted into the configuratio file.

Bookmark+ just has two user options, whose values
are lists of prefix keys.  (The value will usually
be a singleton list - just one prefix key, but if
you want more...)

`bmkp-bookmark-map-prefix-keys' - default: `C-x x'
`bmkp-jump-map-prefix-keys'     - default: `C-x j'

[But Emacs has just decided to usurp `C-x x' for
a default binding.  Previously, the Bookmark+
default was `C-x p', but then Emacs usurped that
for its Project library, so I changed to `C-x x'.
You get the picture - why 3rd-party code could
use a break from Emacs claiming more territory
for default bindings.]

You can set either option to nil to not have any
such prefix key.  And you can easily change to
different prefix keys.  You need not know anything
about how to create or bind prefix keys.

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

[Gregory Heytings]

>
> FWIW, I disagree with Gregory's proposal, which is a scaled-down version 
> of my proposal, which is to reserve _ALL_ keys currently not bound by 
> default, for 3rd-parties to use.  He proposes to reserve only one key 
> for that.
>

That's not the proposal, that's the way you look at the proposal.  The 
proposal is to free one or two keys, and to reserve them for third-party 
libraries.  Freeing one or two keys is (would be) an effort from the 
viewpoint of Emacs, which would give more freedom to both Emacs (to use 
the other keys as it wishes) and to third-party libraries (to use these 
keys as they wish).

Your proposal, "to reserve _ALL_ keys currently not bound by default", has 
I fear no chance whatsoever to be adopted.  Emacs evolves, and deciding 
that it cannot bind any new key from now on would be an arbitrary 
constraint that would impair its evolution.

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

[Drew Adams]

> > FWIW, I disagree with Gregory's proposal, which is a scaled-down
> > version of my proposal, which is to reserve _ALL_ keys currently
> > not bound by default, for 3rd-parties to use.  He proposes to
> > reserve only one key for that.
> 
> That's not the proposal, that's the way you look at
> the proposal.  The proposal is to free one or two keys,

You clearly said _one_ key, many times.  Glad to
hear now that it's two keys (or at least "1 or 2").

> and to reserve them for third-party libraries.  Freeing one or two
> keys is (would be) an effort from the viewpoint of Emacs,

Not if they're currently not bound by default.
Those are the keys I spoke of: keys not already
bound by default.

> which would give more freedom to both Emacs (to use the other
> keys as it wishes)

Emacs already has that freedom.  And it's using
it more and more, narrowing the set of keys not
bound by default.  It's getting pretty tight.
In the last year I've had to move a prefix key
I use _twice_ now.

> and to third-party libraries (to use these
> keys as they wish).

> Your proposal, "to reserve _ALL_ keys currently not
> bound by default", has I fear no chance whatsoever
> to be adopted.

It certainly has no chance if it's not even
proposed.  And your immediate subsequent
pull-back proposal hasn't helped.

> Emacs evolves, and deciding that it cannot bind any
> new key from now on would be an arbitrary
> constraint that would impair its evolution.

1. I proposed a _moratorium_.
2. I explicitly said that maintainers could override
   it, and that it would be good to solicit discussion
   before doing so.

Instead of designating some single prefix key as
reserved for 3rd-party use, why not just have
Emacs lay off binding keys by default for a while?

There are a bunch of keys still available, though
there's been more encroachment recently.  My ask
is just to put up a sign, "Wilderness area, no
further development now, please".  Your proposal
is to designate a tiny patch as the only area to
protect from development.

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: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

> >> That's not the proposal, that's the way you look at the proposal.
> >> The proposal is to free one or two keys,
> >
> > You clearly said _one_ key, many times.  Glad to hear now that it's
> > two keys (or at least "1 or 2").
> >
> >> and to reserve them for third-party libraries.  Freeing one or two
> >> keys is (would be) an effort from the viewpoint of Emacs,
> >
> > Not if they're currently not bound by default.
> 
> I wonder: did you actually read the proposal?

Yes.  There's no effort needed if all keys not
currently bound are explicitly freed from use
for default Emacs key bindings.  A fortiori,
for just one or two of them.

Of _them_ - the unbound keys.

Of course if keys that are currently bound by
default are to be freed up then some adjustment
would need to be made.  But no effort is needed
for keys not yet bound - zero, beyond documenting
the fact.

By proposing to free up keys already bound, you
create more effort than is needed (zero), and you
solicit just the kind of back-&-forth objections
that have ensued: this key vs that key: Which
ones should be freed for 3rd-party code?  And
what if we switched this and that?  Or we did
this instead?  Or...?

The simple answer, as a starting point, is _none_
of those keys.  Just free up keys that are not
yet taken, just say that Emacs won't take them.

Additional discussion about possibly freeing up
more keys, which are currently taken, is also
welcome, but it should be separate from staking
out, now, the currently unbound keys as reserved
for 3rd parties.

Additional discussion about possibly refactoring
Emacs key bindings is also welcome.  And there
too I've participated.  There are repeatable keys
whose bindings are currently wasted.  There are
keys whose commands are not so useful or not so
commonly used.  There are keys that would be
better off used as prefix keys.  All of that is
ripe terrain for making keys more useful and
more available.

But all of that entails arguing about _changing_
existing keys, which as you well know is iffy,
risky territory.

My proposal is to separate any and all such
possible default key-binding _changes_ from the
simple act of declaring the keys so far unbound
by default to be reserved for 3rd-party code.

No default keys to relearn or fight over.  Just
a declaration of a moratorium on using up the
remaining virgin keyspace territory.

> >> Your proposal, "to reserve _ALL_ keys currently
> >> not bound by default", has I fear no chance
> >> whatsoever to be adopted.
> >
> > It certainly has no chance if it's not even
> > proposed.  And your immediate subsequent
> > pull-back proposal hasn't helped.
> 
> I'm sorry to read you've seen it as a pull back.
> What I saw was that your request was being ignored,
> and I tried to help with something more constructive.

I would welcome any such support, if that really
is your intention.

It took decades just to get `transient-mark-mode'
turned on by default.  Same thing for `font-lock-mode'.

I have no illusions about how difficult change is.
But there's no failing like not being willing to
propose something just because it looks hard to
get passed.  There's no failing like giving up
without trying.

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: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

> > But no effort is needed for keys not yet bound
> > - zero, beyond documenting the fact.
>
> The effort, or the absence of effort, is not the
> important point here.

You're the one who brought up the "effort" needed
by Emacs to carry out this or that proposed change.
You claimed that your proposal needed less effort.
I argued that it needs more effort (> zero).

This was important enough that you brought it up.
Now it's not important.  OK.

> The main point is freedom: give more freedom to both Emacs and third-
> party libraries.  And "documenting the fact that keys not yet bound
> cannot be bound anymore" hinders Emacs' freedom.  I know, you also said that
> "exceptions would be possible with the approval of maintainers", but
> that's precisely what happened with the new "C-x x" key, and you
> objected anyway.

Maintainers decide.  I accept that - that's their
role, always, including on those occasions where
I might disagree.

The entire discussion was brought to emacs-devel
- not by me - from a bug thread, where `C-x x'
was taken over willy nilly, yes, over my objection.

And the bug/enhancement request was much narrower.
The decision was to bind a _global_ key by default.
Gigantic overkill, for the narrow problem raised
by the bug report.

I agreed (in emacs-devel, when discussed there,
and in the bug thread before that) that such wide
decisions - wider than the bug thread - should
preferably follow wider discussion in emacs-devel.

Half of the discussion in emacs-devel was/is about
this problem that some big, wide-ranging change
gets made in a bug thread, without many eyes seeing
it or minds discussing it.  That's a problem (IMO
- the maintainers disagree).

Wrt the actual change made:

I objected that, within the last year, first prefix
key `C-x p' was taken over, so I changed my code
to use `C-x x' instead, and now `C-x x' was also
taken over.  That's quite a bit to lose in a year.
And both changes were made in bug threads - no
discussion in emacs-devel.

I objected to that, and I still object.  It's not
I who decide, and that's fine.  But my opinion
that this isn't a good change, and that such things
should be discussed in emacs-devel, remains.

I'm not so worried as you about Emacs's "freedom"
to bind the keys it wants.  Casting this as a
question of "freedom" is alarmist and ridiculous,
IMO.  This is a question about what key-binding
conventions we should have, nothing more.

> > My proposal is to separate any and all such
> > possible default key-binding _changes_ from
> > the simple act of declaring the keys so far
> > unbound by default to be reserved for
> > 3rd-party code.
> 
> That just can't happen, it would be a arbitrary constraint that would
> impair Emacs' evolution, it would mean that hundreds of small or large
> potential improvements would not be possible anymore.

Not at all.  It would mean that Emacs would try
harder not to add new default key bindings.  It's
not trying hard enough now - that's the problem.
IMO, it's gotten worse lately, when we can least
afford it (available keys are scarcer and scarcer).

I asked for other solutions to the problem (still
asking).  And the maintainer's reply was that
there is no problem.

Yes, you proposed another answer to the problem,
and that's fine.  It's not as good an answer as
mine, IMO, but at least you offered something.

> > I would welcome any such support, if that
> > really is your intention.
> 
> FWIW, it was indeed really my intention.  The proposal is an attempt to
> find a reasonable middle ground that would give as much freedom as
> possible to Emacs, as much freedom as possible to third-party library
> developers, and without changing users' habits too much.

That's a good intention, though the ideas that
this is about "freedom", and that Emacs needs
more "freedom" to add default key bindings,
are misguided, IMO.

And as I said, by proposing to use a currently
bound key for this you increase, not decrease,
the contention and argument over which keys
Emacs should "lose" to this, and you increase,
not decrease, the need for users to change habits.

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

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

Drew Adams wrote:

>>> But no effort is needed for keys not yet bound - zero,
>>> beyond documenting the fact.
>>
>> The effort, or the absence of effort, is not the important
>> point here.
>
> You're the one who brought up the "effort" needed by Emacs
> to carry out this or that proposed change. You claimed that
> your proposal needed less effort. I argued that it needs
> more effort (> zero).
>
> This was important enough that you brought it up. Now it's
> not important. OK.
>
>> The main point is freedom: give more freedom to both Emacs
>> and third- party libraries. And "documenting the fact that
>> keys not yet bound cannot be bound anymore" hinders Emacs'
>> freedom. I know, you also said that "exceptions would be
>> possible with the approval of maintainers", but that's
>> precisely what happened with the new "C-x x" key, and you
>> objected anyway.
>
> Maintainers decide. I accept that - that's their role,
> always, including on those occasions where I might disagree.
>
> The entire discussion was brought to emacs-devel - not by me
> - from a bug thread, where `C-x x' was taken over willy
> nilly, yes, over my objection.
>
> And the bug/enhancement request was much narrower.
> The decision was to bind a _global_ key by default.
> Gigantic overkill, for the narrow problem raised by the
> bug report.
>
> I agreed (in emacs-devel, when discussed there, and in the
> bug thread before that) that such wide decisions - wider
> than the bug thread - should preferably follow wider
> discussion in emacs-devel.
>
> Half of the discussion in emacs-devel was/is about this
> problem that some big, wide-ranging change gets made in
> a bug thread, without many eyes seeing it or minds
> discussing it. That's a problem (IMO - the maintainers
> disagree).
>
> Wrt the actual change made:
>
> I objected that, within the last year, first prefix key `C-x
> p' was taken over, so I changed my code to use `C-x x'
> instead, and now `C-x x' was also taken over. That's quite
> a bit to lose in a year. And both changes were made in bug
> threads - no discussion in emacs-devel.
>
> I objected to that, and I still object. It's not I who
> decide, and that's fine. But my opinion that this isn't
> a good change, and that such things should be discussed in
> emacs-devel, remains.
>
> I'm not so worried as you about Emacs's "freedom" to bind
> the keys it wants. Casting this as a question of "freedom"
> is alarmist and ridiculous, IMO. This is a question about
> what key-binding conventions we should have, nothing more.
>
>>> My proposal is to separate any and all such possible
>>> default key-binding _changes_ from the simple act of
>>> declaring the keys so far unbound by default to be
>>> reserved for 3rd-party code.
>> 
>> That just can't happen, it would be a arbitrary constraint
>> that would impair Emacs' evolution, it would mean that
>> hundreds of small or large potential improvements would not
>> be possible anymore.
>
> Not at all. It would mean that Emacs would try harder not to
> add new default key bindings. It's not trying hard enough
> now - that's the problem. IMO, it's gotten worse lately,
> when we can least afford it (available keys are scarcer and
> scarcer).
>
> I asked for other solutions to the problem (still asking).
> And the maintainer's reply was that there is no problem.
>
> Yes, you proposed another answer to the problem, and that's
> fine. It's not as good an answer as mine, IMO, but at least
> you offered something.
>
>>> I would welcome any such support, if that really is
>>> your intention.
>> 
>> FWIW, it was indeed really my intention. The proposal is an
>> attempt to find a reasonable middle ground that would give
>> as much freedom as possible to Emacs, as much freedom as
>> possible to third-party library developers, and without
>> changing users' habits too much.
>
> That's a good intention, though the ideas that this is about
> "freedom", and that Emacs needs more "freedom" to add
> default key bindings, are misguided, IMO.
>
> And as I said, by proposing to use a currently bound key for
> this you increase, not decrease, the contention and argument
> over which keys Emacs should "lose" to this, and you
> increase, not decrease, the need for users to change habits.

If only you could be passionate about it!

But seriously now, I thought people had just got a bit crazy
like they sometimes do, but reading this long post I realize
I missed something... What has happened? Can anyone summarize
it i one or to paragraphs instead of ~20?

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

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

[Drew Adams]

> I realize I missed something... What has happened?
> Can anyone summarize it i one or to paragraphs
> instead of ~20?

Here's my summary (1-9).  Others might see it
differently.  And it's possible that I don't
remember some details perfectly.  Someone will
correct me if I'm mistaken somewhere.

1. Bug #46151, "Set revert-buffer-function in shell
   command output buffers", proposed binding a key for
   `revert-buffer' in shell command buffers (only).

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

2. A discussion in that bug thread led to discussion
   of whether Emacs needs a _global_ key binding for
   `revert-buffer'.

   My own opinion was this:

     Overall, my opinion is to NOT bind it by default.
     Yes, it's useful.

     But it's also easy to do with `M-x revert'.  (And
     then repeat that as a previous command, as needed.)

     And it has many existing bindings, for modes where
     it's used frequently.

   Some others agreed that we need no global binding
   for `revert-buffer'.  If interested, see the thread
   for the discussion.

3. The bug-thread discussion then went toward binding it
   to a global key under `C-x'.  My position was not only
   that we need no global binding for it, but that `C-x',
   in particular, should at this point be left alone.  I 
   explained that I already was forced to move from using 
   prefix key `C-x p' to `C-x x' etc.  I said:

     Users and 3rd-party libraries should really start to
     take precedence now, IMHO.  Emacs should try not to
     bind any more keys by default - starting with `C-x'.
     And certainly for things like `revert-buffer', which
     have survived for 35 years without a default binding.
     YAGNI.

4. Maintainer Lars bound `revert-buffer' globally to
   `C-x g', and closed the shell buffer bug.

5. User Ergus posted in emacs-devel about that,
   complaining that the question should have been
   discussed in emacs-devel (the consequences are
   wider than just shell buffers).

6. A long discussion ensued in emacs-devel.  In
   that discussion I agreed that when a bug-thread
   discussion moves beyond the bug to wider questions
   with wide consequences it should preferably be
   moved to emacs-devel.

   And I repeated my disagreement about globally
   binding `revert-buffer', and in particular about
   binding it to something on `C-x'.  I repeated my 
   suggestion that Emacs desist for a while from
   binding any new keys - at least that it try and
   have that as a convention/goal, and that we
   reserve those remaining keys for use by 3rd-party
   libraries.  Gregory proposed instead that we
   just reserve one key under `C-x', for use as a
   prefix key by 3rd-party code.

7. The main maintainer, Eli, disagreed that questions
   wider than a bug's subject should generally be
   brought to emacs-devel, and he supported the
   decision to bind `revert-buffer' to `C-x g'.

   Other users spoke up complaining about that key, 
   suggesting other keys for it, and so on.  Each
   time a key was suggested someone invariably
   complained.  (Not I - my disagreement is more
   general - I would no global key to be bound to
   it by default.)

8. There was also discussion about the problem of
   people in emacs-devel not being aware of the
   details of this or that bug report, IOW, _how_
   to make the wider group be aware of some bug
   discussion that's grown wider and should maybe
   be moved to emacs-devel.

9. That's pretty much where we are, I think.  Again,
   I may have forgotten something here or there.  I
   haven't intentionally left anything out.

___

Here's the summary of my position, from that bug thread:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46151#88

And here's a longer post of mine about the various
questions - a summary, but not short.

https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg00312.html

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

[Drew Adams]

I should have also mentioned bug #46300 in this regard:
"Move revert-buffer global binding into a prefix map"

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

It was a follow-up to the discussion for bug #46151.

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

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

Drew Adams wrote:

>> I realize I missed something... What has happened?
>> Can anyone summarize it i one or to paragraphs instead of
>> ~20?
>
> Here's my summary (1-9). Others might see it differently.
> And it's possible that I don't remember some details
> perfectly. Someone will correct me if I'm
> mistaken somewhere.

OK, thanks, but why is this such a big deal/sensitive issue?

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

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

[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

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

>
> 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: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-09 20:50]:
> 
> > 
> > FWIW, I disagree with Gregory's proposal, which is a scaled-down version
> > of my proposal, which is to reserve _ALL_ keys currently not bound by
> > default, for 3rd-parties to use.  He proposes to reserve only one key
> > for that.
> > 
> 
> That's not the proposal, that's the way you look at the proposal.  The
> proposal is to free one or two keys, and to reserve them for third-party
> libraries.  Freeing one or two keys is (would be) an effort from the
> viewpoint of Emacs, which would give more freedom to both Emacs (to use the
> other keys as it wishes) and to third-party libraries (to use these keys as
> they wish

Unbound key I found is M-n and there are those like M-[ M and M-] 

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

[Thibaut Verron]

2021-02-10 12:33 UTC+01:00, Jean Louis <bugs@gnu.support>:
> * Gregory Heytings <gregory@heytings.org> [2021-02-09 20:50]:
>>
>> >
>> > FWIW, I disagree with Gregory's proposal, which is a scaled-down
>> > version
>> > of my proposal, which is to reserve _ALL_ keys currently not bound by
>> > default, for 3rd-parties to use.  He proposes to reserve only one key
>> > for that.
>> >
>>
>> That's not the proposal, that's the way you look at the proposal.  The
>> proposal is to free one or two keys, and to reserve them for third-party
>> libraries.  Freeing one or two keys is (would be) an effort from the
>> viewpoint of Emacs, which would give more freedom to both Emacs (to use
>> the
>> other keys as it wishes) and to third-party libraries (to use these keys
>> as
>> they wish
>
> Unbound key I found is M-n and there are those like M-[ M and M-]

M-n (and its sister M-p) are used for navigating history in a lot of modes.

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

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Wed, 10 Feb 2021 12:41:17 +0100
> 
> M-n (and its sister M-p) are used for navigating history in a lot of modes.

Not just history; any mode where next/previous item makes sense.  For
example, Rmail binds it to a command that shows the next email
message.

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

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2021-02-09 20:14]:
> > So I think there is no need to reserve more keys for third party
> > packages. Finally, keys are limited.
> 
> The question is not about reserving keys
> for 3rd-party use _from users_.  It's about
> reserving them from Emacs itself, i.e., so
> they don't become new _default_ bindings.

Sure I understand that. The point from me was that those keys reserved
for users can be advised for use by third party packages just as the
Org mode does it. In my opinion there is no problem there. Org mode
suggests users to bind let us say {C-c c} for `org-capture' and so
many do. In the same way can do also other packages.

Such keys are then not bound by the package automatically but reserved
for users.

For example I do not mind pressing {C-x v v} for version control, so I
would not mind typing {C-c o KEY} for org related functions. Then
maybe piece of artificial intelligence or simple description in the
package would advise me to set `C-c o' as a prefix for org related
functions, and I would be set.

Then for magit I could set `C-c m' as magit related prefix and I could
use anything there like {C-c m g} or anything. Though I do not use
magit. It is example.

So maybe people discuss here about keys to be reserved for automated
bindings, to let the package authors decide which key to bind that
will not conflict with any of Emacs keys and none of user defined
keys.

I see that those keys reserved for users should be suggested by
packages. Like package could say "Use one of F5-F9 as prefix key for
Magit"

Using Super key like that key between Control and Aternative Control
that may have Windoze logo on it is very handy on X, but not so handy
in console. It may not work without special setups. If some automated
solution is found in Emacs for Super key to work in console the same
as in X, then that could be door to opening many new keys for
reservations.

General problem is that Emacs needs many keys. I would like having the
keyboard with more modifiers.

Jean

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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

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

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

> 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

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

[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

[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

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

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