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

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

[Drew Adams]

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

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

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

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

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

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

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

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

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

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

[Drew Adams]

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

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

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

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

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

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