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

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

[Gregory Heytings]

=Proposal=

It is proposed to repurpose one key, and to reserve it in the key binding 
conventions for third-party packages.  The keys that could be reserved for 
that purpose are:

Option 1. C-z, with a single exception: "C-z C-z" would be bound to 
"suspend-frame"

Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound to 
"suspend-frame", and "M-z M-z" to "zap-to-char"

Option 3. C-o, with a single exception: "C-o C-o" would be bound to 
"open-line"

Option 4. C-o and M-o, with two exceptions: "C-o C-o" would be bound to 
"open-line", and "M-o M-o" to "facemenu-keymap"

=Rationale=

The current key binding conventions (see `(elisp) Key Binding 
Conventions') reserve keys for users, for major modes and for minor modes, 
but not for third-party packages [1].

When such packages need to bind a command to a key, they can (1) either 
suggest users to bind it to a key reserved for users (for example, 
org-mode suggests to globally bind "C-c c" to org-capture), or (2) bind it 
to a key currently unused by Emacs (for example, Magit binds "C-x g" to 
magit-status in buffers visiting a file in a Git repository).

Neither of these solutions are optimal: (1) requires an explicit 
configuration by the user, something which might confuse newcomers, and 
which other users might not want to do because they already use the keys 
reserved for users for other purposes, and (2) might conflict with the 
evolution of Emacs when one or more commands are bound to a yet unused 
key.

Reserving one key for third-party packages solves the above problems: 
third-party packages can automatically bind a few keys in that reserved 
area, without conflicting with keys reserved for users and without 
conflicting with future Emacs evolutions.

=Limit=

Conflicts are still possible, when two or more packages bind the same 
keys.  These are, however, conflicts between packages, not between a 
package and Emacs, or between a package and users' personal 
configurations.

Such conflicts are also less likely for typical users, who install a few 
packages each binding a few keys.

Finally, such conflicts can be dealt with without confusing users too 
much: a package could automatically choose fallback key bindings when the 
preferred ones are already used by another package, and/or issue a warning 
to the user that they need to bind its commands manually.

=Note=

[1] These conventions were written 25 years ago, at a time when there were 
far fewer third-party packages, and have not changed substantially since 
them.

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

[Ergus]

Hi Gregory:

IMO We shouldn't try to change C-o if we want an agreement. But all the
changes sound reasonable due to the current situation. In other editors
C-o is open file... just to say.

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

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

[Jorge Javier Araya Navarro]

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

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

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

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

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Option 1. C-z, with a single exception: "C-z C-z" would be bound to 
  > "suspend-frame"

I think that these changes for C-z, M-z and C-o would be a big pain in
the neck.

However, it would be possible to make M-z M-ANYTHING available for
other bindings and reserve them for whatever we wish.  That would not
conflict with the current meaning of M-z, because meta characters
can't be in the buffer.

The binding of M-m is less useful than many other keys.
Perhaps it could be given to some other use.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

>   > Option 1. C-z, with a single exception: "C-z C-z" would be bound to
>   > "suspend-frame"
>
> I think that these changes for C-z, M-z and C-o would be a big pain in
> the neck.

Indeed.

(But I personally still maintain that `C-z' should just be changed to
`undo'.)

> However, it would be possible to make M-z M-ANYTHING available for
> other bindings and reserve them for whatever we wish.  That would not
> conflict with the current meaning of M-z, because meta characters
> can't be in the buffer.

Wouldn't it be strange to first be queried for "Zap up to char: " and
then be expected to type another key to run some command from a
third-party package?

> The binding of M-m is less useful than many other keys.
> Perhaps it could be given to some other use.

Your mileage may vary, but I use `M-m' tens or hundreds of time per day.

Of the global M-bindings, `M-o' seems least useful to me.

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

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> (But I personally still maintain that `C-z' should just be changed to
> `undo'.)

The problem is that `C-z' is really useful in a terminal, and having the
keystrokes diverge to a great degree between GUI Emacs and terminal
Emacs would be unfortunate.

> Of the global M-bindings, `M-o' seems least useful to me.

Indeed.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Gregory Heytings]

>> (But I personally still maintain that `C-z' should just be changed to 
>> `undo'.)
>
> The problem is that `C-z' is really useful in a terminal, and having the 
> keystrokes diverge to a great degree between GUI Emacs and terminal 
> Emacs would be unfortunate.
>

Indeed, C-z is useful in terminals, even though suspend-frame is also 
available on C-x C-z.  Terminals are the reason why the proposal mentions 
that C-z C-z would be (the only) reserved binding in that keymap. 
Repeating a key until it produces the expected effect is something 
terminal users are habituated to do (for example repeating C-c until the 
program aborts).

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

[Stefan Monnier]

> The problem is that `C-z' is really useful in a terminal, and having the
> keystrokes diverge to a great degree between GUI Emacs and terminal
> Emacs would be unfortunate.
>> Of the global M-bindings, `M-o' seems least useful to me.
> Indeed.

And yet the corresponding feature is *preloaded* :-(


        Stefan "whose M-o is unbound because his local Emacs patches
                include removing that part of loadup.el"


PS: It took me a bit if digging to figure out why my M-o was unbound.
That's a change I made a very long time ago.

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

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The problem is that `C-z' is really useful in a terminal, and having the
>> keystrokes diverge to a great degree between GUI Emacs and terminal
>> Emacs would be unfortunate.
>>> Of the global M-bindings, `M-o' seems least useful to me.
>> Indeed.
>
> And yet the corresponding feature is *preloaded* :-(
>
>         Stefan "whose M-o is unbound because his local Emacs patches
>                 include removing that part of loadup.el"
>
> PS: It took me a bit if digging to figure out why my M-o was unbound.
> That's a change I made a very long time ago.

We've previously discussed doing time-limited experiments -- perhaps
this is a good test case for that.

That is, I propose that we remove the `M-o' binding on the trunk for one
month, and see how many (if any) complaints we get.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Sean Whitton]

Hello,

On Tue 09 Feb 2021 at 09:13AM +01, Lars Ingebrigtsen wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> The problem is that `C-z' is really useful in a terminal, and having the
>>> keystrokes diverge to a great degree between GUI Emacs and terminal
>>> Emacs would be unfortunate.
>>>> Of the global M-bindings, `M-o' seems least useful to me.
>>> Indeed.
>>
>> And yet the corresponding feature is *preloaded* :-(
>>
>>         Stefan "whose M-o is unbound because his local Emacs patches
>>                 include removing that part of loadup.el"
>>
>> PS: It took me a bit if digging to figure out why my M-o was unbound.
>> That's a change I made a very long time ago.
>
> We've previously discussed doing time-limited experiments -- perhaps
> this is a good test case for that.
>
> That is, I propose that we remove the `M-o' binding on the trunk for one
> month, and see how many (if any) complaints we get.

Aren't the current bindings under M-o intended for that halcyon future
in which we can use Emacs as a word processor, not just a text editor?
Like enriched-mode, but for file formats like .odt, where buffer faces
set with M-o get translated into something in the file format upon save.

I assume that most of the bindings under M-o were made with that sort of
usage of Emacs in mind.  It strikes me as a bit sad to unbind M-o as it
would sort of be saying that we no longer think Emacs is ever going to
be much use for editing non-plain text.

-- 
Sean Whitton

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

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Aren't the current bindings under M-o intended for that halcyon future
> in which we can use Emacs as a word processor, not just a text editor?
> Like enriched-mode, but for file formats like .odt, where buffer faces
> set with M-o get translated into something in the file format upon save.

That's my guess, but they make little sense as global bindings.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Tue, 09 Feb 2021 09:54:59 -0700
> Cc: Gregory Heytings <gregory@heytings.org>,
>  Stefan Kangas <stefankangas@gmail.com>, rms@gnu.org, emacs-devel@gnu.org
> 
> Aren't the current bindings under M-o intended for that halcyon future
> in which we can use Emacs as a word processor, not just a text editor?
> Like enriched-mode, but for file formats like .odt, where buffer faces
> set with M-o get translated into something in the file format upon save.
> 
> I assume that most of the bindings under M-o were made with that sort of
> usage of Emacs in mind.  It strikes me as a bit sad to unbind M-o as it
> would sort of be saying that we no longer think Emacs is ever going to
> be much use for editing non-plain text.

We could make these bindings local to the modes where they are
relevant, for example Text mode and its descendants.  There's no need
for a global binding, at least not necessarily.

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

[Sean Whitton]

Hello,

On Tue 09 Feb 2021 at 07:43PM +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Date: Tue, 09 Feb 2021 09:54:59 -0700
>> Cc: Gregory Heytings <gregory@heytings.org>,
>>  Stefan Kangas <stefankangas@gmail.com>, rms@gnu.org, emacs-devel@gnu.org
>>
>> Aren't the current bindings under M-o intended for that halcyon future
>> in which we can use Emacs as a word processor, not just a text editor?
>> Like enriched-mode, but for file formats like .odt, where buffer faces
>> set with M-o get translated into something in the file format upon save.
>>
>> I assume that most of the bindings under M-o were made with that sort of
>> usage of Emacs in mind.  It strikes me as a bit sad to unbind M-o as it
>> would sort of be saying that we no longer think Emacs is ever going to
>> be much use for editing non-plain text.
>
> We could make these bindings local to the modes where they are
> relevant, for example Text mode and its descendants.  There's no need
> for a global binding, at least not necessarily.

I agree that it would be good to find a non-global way to do this.

Perhaps we could set up a major mode to be inherited by modes like
enriched-mode, which sets up a binding which is at least as convenient
to use as M-o is right now?

That way we can ensure that the bindings to set faces are consistent
between major modes, which is what we would be at risk of losing if we
drop the global binding.

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

Does this sound sensible?  It would be a shame if we ended up with each
possible WYSIWYG mode defining its own face-setting bindings.

Also, new non-WYSIWYG modes could re-use the same bindings to, e.g.,
insert asterisks around text meant to be bold.

-- 
Sean Whitton

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

[Kévin Le Gouguec]

Sean Whitton <spwhitton@spwhitton.name> writes:

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

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

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

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

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

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

[Stefan Monnier]

> I assume that most of the bindings under M-o were made with that sort of
> usage of Emacs in mind.

That's my impression as well.

> It strikes me as a bit sad to unbind M-o as it would sort of be saying
> that we no longer think Emacs is ever going to be much use for editing
> non-plain text.

No, I think it's just normal: if/when you want to use Emacs as a WYSISYG
editor, it'll have to be in a dedicated (set of) modes.  Those can then
provide bindings like the ones we currently have under M-o.  But having
those bindings in the global map just doesn't make much sense.


        Stefan

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> (But I personally still maintain that `C-z' should just be changed to
>> `undo'.)
>
> The problem is that `C-z' is really useful in a terminal, and having the
> keystrokes diverge to a great degree between GUI Emacs and terminal
> Emacs would be unfortunate.

Yes, those are valid concerns.

OTOH, we also provide `C-x C-z'.  My personal preference would be for
Emacs to be weird in having suspend [in terminal] on a non-conventional
key, rather than undo [in terminal and GUI].  But that's me.

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

[Thibaut Verron]

>> The binding of M-m is less useful than many other keys.
>> Perhaps it could be given to some other use.
>
> Your mileage may vary, but I use `M-m' tens or hundreds of time per day.

I'm also using it a lot, so much actually that I rebound it to C-a
(with a test so that C-a C-a does beginning-of-line). So I would not
miss M-m at all.

Do you also use plain C-a (in scenarios where it disagrees with M-m)
hundreds of times per day?

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

[Stefan Kangas]

Thibaut Verron <thibaut.verron@gmail.com> writes:

>> Your mileage may vary, but I use `M-m' tens or hundreds of time per day.
>
> I'm also using it a lot, so much actually that I rebound it to C-a
> (with a test so that C-a C-a does beginning-of-line).

I never considered making such a binding globally.  It's a good idea.

(I don't want to fan the flames, but this makes me wonder why `C-a' does
not already default to this behavior...)

> Do you also use plain C-a (in scenarios where it disagrees with M-m)
> hundreds of times per day?

Yes, I use `C-a' more frequently than `M-m'.

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

[Drew Adams]

> >> I use `M-m' tens or hundreds of time per day.
> >
> > I'm also using it a lot, so much actually that I rebound it to C-a
> > (with a test so that C-a C-a does beginning-of-line).
> 
> I never considered making such a binding globally.  It's a good idea.
> 
> (I don't want to fan the flames, but this makes me wonder why `C-a'
> does not already default to this behavior...)

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

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

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

> > Do you also use plain C-a (in scenarios where
> > it disagrees with M-m) hundreds of times per day?
> 
> Yes, I use `C-a' more frequently than `M-m'.

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

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

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

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


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

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

[Simen Heggestøyl]

Stefan Kangas <stefankangas@gmail.com> writes:

> Thibaut Verron <thibaut.verron@gmail.com> writes:
>
>>> Your mileage may vary, but I use `M-m' tens or hundreds of time per day.
>>
>> I'm also using it a lot, so much actually that I rebound it to C-a
>> (with a test so that C-a C-a does beginning-of-line).
>
> I never considered making such a binding globally.  It's a good idea.
>
> (I don't want to fan the flames, but this makes me wonder why `C-a' does
> not already default to this behavior...)

I also like this behavior. I made the same binding as Thibaut many years
ago, and have never missed the old behavior.

-- Simen

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

[Juri Linkov]

>>> Your mileage may vary, but I use `M-m' tens or hundreds of time per day.
>>
>> I'm also using it a lot, so much actually that I rebound it to C-a
>> (with a test so that C-a C-a does beginning-of-line).
>
> I never considered making such a binding globally.  It's a good idea.
>
> (I don't want to fan the flames, but this makes me wonder why `C-a' does
> not already default to this behavior...)

For a long time I have been using such logic bound to `C-a':

  (if (bolp)
      (beginning-of-line-text arg)   ;; or (back-to-indentation)
    (if (fboundp 'move-beginning-of-line)
        (move-beginning-of-line arg)
      (beginning-of-line arg)))

But I don't remember the difference between beginning-of-line-text and
back-to-indentation and which one is better, neither the difference
between beginning-of-line and move-beginning-of-line.

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

[Gregory Heytings]

>
> For a long time I have been using such logic bound to `C-a':
>
>  (if (bolp)
>      (beginning-of-line-text arg)   ;; or (back-to-indentation)
>    (if (fboundp 'move-beginning-of-line)
>        (move-beginning-of-line arg)
>      (beginning-of-line arg)))
>
> But I don't remember the difference between beginning-of-line-text and 
> back-to-indentation and which one is better, neither the difference 
> between beginning-of-line and move-beginning-of-line.
>

The main difference between back-to-indentation and beginning-of-line-text 
is that back-to-indentation ignores the fill-prefix.  With a buffer with 
the following two lines:

      1234
>>>> 5678

with point on "4:
- move-beginning-of-line moves point to the beginning of the line
- back-to-indentation moves point to "1"
- beginning-of-line-text moves point to "1"

with point on "8":
- move-beginning-of-line moves point to the beginning of the line
- back-to-indentation moves point to the beginning of the line
- beginning-of-line-text moves point to "5"

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

[Gregory Heytings]

>
> (But I personally still maintain that `C-z' should just be changed to 
> `undo'.)
>

IMO that would be the worst possible binding for C-z.  "Undo" is already 
bound to no less than three different keys.  Binding it to yet another key 
just to make Emacs feel closer to other editors, when all other bindings 
are so different from other editors anyway, would (IMO again) be a serious 
mistake.

>
> Of the global M-bindings, `M-o' seems least useful to me.
>

Leaving just one meta key (in this case M-o) for third-party packages 
would IMO not be enough to motivate their developers to put their default 
bindings there; third-party packages should not be considered as 
second-class citizens.  It must either be a control key alone, or a 
control key and its corresponding meta key.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > However, it would be possible to make M-z M-ANYTHING available for
  > > other bindings and reserve them for whatever we wish.  That would not
  > > conflict with the current meaning of M-z, because meta characters
  > > can't be in the buffer.

  > Wouldn't it be strange to first be queried for "Zap up to char: " and
  > then be expected to type another key to run some command from a
  > third-party package?

Yes, it would be -- but we can deal with that.
The promp could say  "Next Meta-character, or zap up to char:".

It could wait a second before prompting, so that experienced users
normally would not wait so long before typing the next key.



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Alan Mackenzie]

Hello, Richard.

On Sun, Feb 07, 2021 at 22:46:37 -0500, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

>   > Option 1. C-z, with a single exception: "C-z C-z" would be bound to 
>   > "suspend-frame"

> I think that these changes for C-z, M-z and C-o would be a big pain in
> the neck.

> However, it would be possible to make M-z M-ANYTHING available for
> other bindings and reserve them for whatever we wish.  That would not
> conflict with the current meaning of M-z, because meta characters
> can't be in the buffer.

> The binding of M-m is less useful than many other keys.  Perhaps it
> could be given to some other use.

Please not.  I use M-m frequently.  If that binding were to be removed,
there would be no good way of doing what it does.  C-a M-f M-b is not
good.  I think the existence of bindings like C-o and M-m is one of the
differences between Emacs and lesser editors that makes Emacs so good.

I don't use C-z or M-z myself, but that's no reason for me to advocate
reassigning those keys to something else.

> -- 
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Gregory Heytings]

>
> I think that these changes for C-z, M-z and C-o would be a big pain in 
> the neck.
>

Could you perhaps elaborate a bit what you mean by this?  For example, why 
would typing "C-z C-z" instead of "C-z" to suspend, something you 
presumably don't do once a minute, be "a big pain in the neck"?

There is a problem in need for a solution.  If nobody agrees to make small 
concessions it will forever remain a problem, with on the one hand 
repeated conflicts and animosity between Emacs and package developers, and 
on the other hand unnecessary complexity to install packages for Emacs 
users.

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

[Robin Tarsiger]

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

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

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

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

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

-RTT

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

[Thibaut Verron]

2021-02-08 5:52 UTC+01:00, Robin Tarsiger <rtt@dasyatidae.com>:
> Gregory Heytings wrote:
>> Option 1. C-z, with a single exception: "C-z C-z" would be bound to
>> "suspend-frame"
>>
>> Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound to
>> "suspend-frame", and "M-z M-z" to
>> "zap-to-char"
>>
>> Option 3. C-o, with a single exception: "C-o C-o" would be bound to
>> "open-line"
>>
>> Option 4. C-o and M-o, with two exceptions: "C-o C-o" would be bound to
>> "open-line", and "M-o M-o" to
>> "facemenu-keymap"
>
> In my own init code, I use f8 as a prefix key for a bunch of custom
> bindings,
> including for global Calc, SLIME, and Org commands. This seems similar in
> general
> nature to the desired use for third-party packages, and I notice that f5--f8
> are
> all available in vanilla Emacs. That would obviously be less disruptive
> than
> repurposing an existing key, but I don't know how reachable those keys are
> in
> everyone's configurations.

https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html

Those keys are explicitly left for the user to define.

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

[Robin Tarsiger]

Thibaut Verron wrote:
[re f5--f8]
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html
> 
> Those keys are explicitly left for the user to define.

D'oh, I thought I checked that. My mistake; never mind.

-RTT "if sleepy, wait until morning before hitting Send"

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

[Arthur Miller]

Thibaut Verron <thibaut.verron@gmail.com> writes:

> 2021-02-08 5:52 UTC+01:00, Robin Tarsiger <rtt@dasyatidae.com>:
>> Gregory Heytings wrote:
>>> Option 1. C-z, with a single exception: "C-z C-z" would be bound to
>>> "suspend-frame"
>>>
>>> Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound to
>>> "suspend-frame", and "M-z M-z" to
>>> "zap-to-char"
>>>
>>> Option 3. C-o, with a single exception: "C-o C-o" would be bound to
>>> "open-line"
>>>
>>> Option 4. C-o and M-o, with two exceptions: "C-o C-o" would be bound to
>>> "open-line", and "M-o M-o" to
>>> "facemenu-keymap"
>>
>> In my own init code, I use f8 as a prefix key for a bunch of custom
>> bindings,
>> including for global Calc, SLIME, and Org commands. This seems similar in
>> general
>> nature to the desired use for third-party packages, and I notice that f5--f8
>> are
>> all available in vanilla Emacs. That would obviously be less disruptive
>> than
>> repurposing an existing key, but I don't know how reachable those keys are
>> in
>> everyone's configurations.
>
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html
>
> Those keys are explicitly left for the user to define.
What I see is missing here, is the most important option: to hire a
secretary to Mr. Eli so he can actually get some work done amongst this
flood of emails going on for days now on this über-important topic of
which key to use or not use ... :-)

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

[Gregory Heytings]

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

That would be the case, by design.  One or two keymaps would be created, 
which you could assign to any other key.  For example you can move all C-x 
bindings to F7 with (progn (define-key global-map (kbd "<f7>") ctl-x-map) 
(define-key global-map (kbd "C-x") nil)).

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

[Yuri Khan]

On Tue, 9 Feb 2021 at 07:37, Gregory Heytings <gregory@heytings.org> wrote:

> For example you can move all C-x
> bindings to F7 with (progn (define-key global-map (kbd "<f7>") ctl-x-map)
> (define-key global-map (kbd "C-x") nil)).

Does it work that easily though? I might like to do that to C-x and
C-c so that I could bind those to Cut and Copy[^1]. But no:

    $ emacs -Q
    (define-key global-map (kbd "<f7>") ctl-x-map) ;; C-x C-e
    (define-key global-map (kbd "C-x") #'kill-region) ;; f7 C-e
    (+ 2 2) ;; C-x C-e ⇒ no effect; f7 C-e ⇒ 4

    C-r buffer RET C-S-right C-x

Expected: the word is killed.

Observed: I get a “C-x-” prompt in the minibuffer, indicating C-x is
still acting as a prefix key. Indeed, pressing C-h reveals a number of
C-x 8 … bindings in key translations, and a bunch of C-x @ … bindings
in function key map translations.

    M-x hl-lock-mode RET
    C-s define-key M-C-B C-x w .

Expected: “define-key” is killed and replaced with “w.”.
Observed: ‘highlight-symbol-at-point’ picks up “define-key” and
highlights its all occurrences.


[^1]: Yes, I know of and use cua-mode. No, it’s not satisfying.
Because with all this pandemic work-from-home, my Emacs is over there
at my office, and it’s displaying its frames on my X server here at my
home[^2], and network lag interferes with the timeout-based heuristic
that causes cua-mode to cut where I intended to do a prefix C-x, or
vice versa, to switch buffers when I intended to cut and then move
point left or right.

[^2]: Yes, I know about Tramp, but have not made it part of my
workflow, partially because I’m unsure if eglot will work over tramp.

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

[Gregory Heytings]

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


>> For example you can move all C-x bindings to F7 with (progn (define-key 
>> global-map (kbd "<f7>") ctl-x-map) (define-key global-map (kbd "C-x") 
>> nil)).
>
> Does it work that easily though?
>

No it doesn't, it was just a short proof of concept, which works mostly.

>
> Observed: I get a “C-x-” prompt in the minibuffer, indicating C-x is 
> still acting as a prefix key. Indeed, pressing C-h reveals a number of 
> C-x 8 … bindings in key translations, and a bunch of C-x @ … bindings in 
> function key map translations.
>

Yes, as Andreas Schwab explained a few days ago in another thread, this is 
because C-x is a prefix key on the key-translation-map.

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

[Stefan Monnier]

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

Yes, focusing on the keymap first and presuming that its actual binding
may change seems important.  Tho in practice, when a keymap is bound
changes which bindings inside the map are convenient to type:
E.g. `C-z C-z` is much easier to type than `M-o C-z`.


        Stefan

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

[Gregory Heytings]

>> I _kind of_ like this general idea because the current situation is 
>> getting kind of hazardous. _But_ if any of these do happen, make sure 
>> the symbol for the sub-keymap is exposed so the user can move the whole 
>> thing somewhere else from init code.
>
> Yes, focusing on the keymap first and presuming that its actual binding 
> may change seems important.  Tho in practice, when a keymap is bound 
> changes which bindings inside the map are convenient to type: E.g. `C-z 
> C-z` is much easier to type than `M-o C-z`.
>

And in practice, too, there is no chance third-party library developers 
would agree to use that keymap if it is not bound by default to a sensible 
key.  It must be an appealing solution.

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

[Augusto Stoffel]

Surely lots of people rebind some non-prefix keys of dubious usefulness
like ‘C-z’ and ‘M-o’ (I bet I'm not alone in using those for
‘switch-to-buffer’ and ‘other-window’ respectively).

Now, as long as there is a _keymap_ for third-party packages, which
users can move wherever they see fit, I wouldn't care about the default
bindings.  But it's important not to leave room for the interpretation
that the third-party keymap will always be bound to its default key.

Best,
Augusto

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

[Gregory Heytings]

>
> Now, as long as there is a _keymap_ for third-party packages, which 
> users can move wherever they see fit, I wouldn't care about the default 
> bindings.  But it's important not to leave room for the interpretation 
> that the third-party keymap will always be bound to its default key.
>

Yes, that would be the case, by design.  One or two keymaps would be 
created, which anyone could move to another key if need be.  The point of 
the proposal is to discuss the default bindings of that keymap/these 
keymaps.  Without sensible default bindings, there's no point in creating 
such keymaps.

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

[Dmitry Gutov]

On 08.02.2021 00:05, Gregory Heytings wrote:
> 
> =Proposal=
> 
> It is proposed to repurpose one key, and to reserve it in the key 
> binding conventions for third-party packages.  The keys that could be 
> reserved for that purpose are:
> 
> Option 1. C-z, with a single exception: "C-z C-z" would be bound to 
> "suspend-frame"
> 
> Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound to 
> "suspend-frame", and "M-z M-z" to "zap-to-char"

This won't fly because a lot of us bind 'C-z' to 'undo' (or a similar 
command), and special-casing 'C-z C-z' would break that usage (calling 
'undo' several times in a row is common).

Finally, like Stefan K said in another thread, if we even end up 
changing the 'C-z' binding, let's finally make it compatible with most 
other editors out there, which is putting 'undo' on it. Or 'undo-only'.

And as a maintainer of multiple packages, I have lost track of how many 
times I switch to 'emacs -Q' to reproduce some bug report, and then end 
up suspending the frame by accident.

> Option 3. C-o, with a single exception: "C-o C-o" would be bound to 
> "open-line"
> 
> Option 4. C-o and M-o, with two exceptions: "C-o C-o" would be bound to 
> "open-line", and "M-o M-o" to "facemenu-keymap"

I'd prefer to keep 'C-o' as-is, but admittedly it's a less important 
binding.

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

[Gregory Heytings]

>
> This won't fly because a lot of us bind 'C-z' to 'undo' (or a similar 
> command), and special-casing 'C-z C-z' would break that usage (calling 
> 'undo' several times in a row is common).
>

You would (of course) still be free to do this, what is proposed is only a 
default keybinding for a new keymap reserved for third-party packages. 
As I said to Stefan K, undo is already on three keys, using (I'm tempted 
to say "wasting") yet another key for this by default would be most 
regrettable.

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

[Sean Whitton]

Hello Gregory,

On Sun 07 Feb 2021 at 10:05PM GMT, Gregory Heytings wrote:

> It is proposed to repurpose one key, and to reserve it in the key binding
> conventions for third-party packages.  The keys that could be reserved for
> that purpose are:
>
> Option 1. C-z, with a single exception: "C-z C-z" would be bound to
> "suspend-frame"
>
> Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound to
> "suspend-frame", and "M-z M-z" to "zap-to-char"
>
> Option 3. C-o, with a single exception: "C-o C-o" would be bound to
> "open-line"
>
> Option 4. C-o and M-o, with two exceptions: "C-o C-o" would be bound to
> "open-line", and "M-o M-o" to "facemenu-keymap"

C-z seems like the obvious choice out of these -- it's a duplicate
binding, there was a lot of support for repurposing it in that recent
thread, and those who were a bit reticent about repurposing were okay
with the idea of C-z C-z suspending the frame with something in the
message area after a single C-z.

Thanks for the proposal.

-- 
Sean Whitton

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

[Eric Abrahamsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello Gregory,
>
> On Sun 07 Feb 2021 at 10:05PM GMT, Gregory Heytings wrote:
>
>> It is proposed to repurpose one key, and to reserve it in the key binding
>> conventions for third-party packages.  The keys that could be reserved for
>> that purpose are:
>>
>> Option 1. C-z, with a single exception: "C-z C-z" would be bound to
>> "suspend-frame"
>>
>> Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound to
>> "suspend-frame", and "M-z M-z" to "zap-to-char"
>>
>> Option 3. C-o, with a single exception: "C-o C-o" would be bound to
>> "open-line"
>>
>> Option 4. C-o and M-o, with two exceptions: "C-o C-o" would be bound to
>> "open-line", and "M-o M-o" to "facemenu-keymap"
>
> C-z seems like the obvious choice out of these -- it's a duplicate
> binding, there was a lot of support for repurposing it in that recent
> thread, and those who were a bit reticent about repurposing were okay
> with the idea of C-z C-z suspending the frame with something in the
> message area after a single C-z.

If C-x C-z is already `suspend-frame', do we really need C-z C-z, too?

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

[Sean Whitton]

Hello,

On Mon 08 Feb 2021 at 02:40PM -08, Eric Abrahamsen wrote:

> If C-x C-z is already `suspend-frame', do we really need C-z C-z, too?

As has been mentioned, the thought is that a terminal user who doesn't
know much about Emacs will probably just hit it a second time if it
doesn't do what they expect.

-- 
Sean Whitton

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Suppose we reserve one key for third-party packages.  Let's refer to
that key as C-α, to avoid specifying which key is chosen.

Various packages will set up their own bindings for it.  If you load
more than one such package, which package's bindings will you get?
How do you get the ones you want?

Here's an idea.

Have one command you can use to specify which package's bindings C-α
will run.  It could be C-α C-α; then individual packages will not give
their own bindings for C-α C-α.

So you can type C-α C-α Foopkg RET, then C-α gives you the Foopkg bindings.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Thibaut Verron]

2021-02-10 6:28 UTC+01:00, Richard Stallman <rms@gnu.org>:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Suppose we reserve one key for third-party packages.  Let's refer to
> that key as C-α, to avoid specifying which key is chosen.
>
> Various packages will set up their own bindings for it.  If you load
> more than one such package, which package's bindings will you get?
> How do you get the ones you want?
>
> Here's an idea.
>
> Have one command you can use to specify which package's bindings C-α
> will run.  It could be C-α C-α; then individual packages will not give
> their own bindings for C-α C-α.
>
> So you can type C-α C-α Foopkg RET, then C-α gives you the Foopkg bindings.

That seems like an extremely valuable binding to sacrifice for a
command which will most likely be only run once.

But maybe we could agree on a specific key, identical on all keymaps,
for that purpose. That would be similar to how C-\alpha ? is currently
reserved for describe-keymap.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > So you can type C-α C-α Foopkg RET, then C-α gives you the Foopkg bindings.

  > That seems like an extremely valuable binding to sacrifice for a
  > command which will most likely be only run once.

Why do you think C-α C-α would be so valuable?  I don't get it.
(This is supposing we have made C-α a prefix for use by external packages.)

  > But maybe we could agree on a specific key, identical on all keymaps,
  > for that purpose. That would be similar to how C-\alpha ? is currently
  > reserved for describe-keymap.

How is that different from what I said?


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Thibaut Verron]

2021-02-11 14:37 UTC+01:00, Richard Stallman <rms@gnu.org>:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > So you can type C-α C-α Foopkg RET, then C-α gives you the Foopkg
> bindings.
>
>   > That seems like an extremely valuable binding to sacrifice for a
>   > command which will most likely be only run once.
>
> Why do you think C-α C-α would be so valuable?  I don't get it.

Because it is easier to press the same key twice than another key.

See for example how many people support freeing C-z while keeping its
current behavior on C-z C-z.

> (This is supposing we have made C-α a prefix for use by external packages.)

I don't understand the suggestion anymore then. What would the
C-\alpha keymap look like? One package on C-\alpha a, one on C-\alpha
b, etc? Or just one on C-\alpha?

>   > But maybe we could agree on a specific key, identical on all keymaps,
>   > for that purpose. That would be similar to how C-\alpha ? is currently
>   > reserved for describe-keymap.
>
> How is that different from what I said?

The choice of a different second key than the prefix C-\alpha. Besides
keeping the valuable repeated binding free, it also allows to have the
same key across keymaps.

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

[Alfred M. Szmidt]

Since Magit is a VC like mode, wouldn't it make more sense to put it
under C-x v?  E.g., why cannot Magit rebind C-x v l -- which I guess
is similar to magit-status or possibly C-x v d.

From a users perspective, making it seemingly a part of VC-mode makes
more sense than trying to make it a special citizen that needs to take
C-x g (or whatever) since it would make it hard to use MaGit,
MaFossil, MaSubersion (last two are fictious) .... together.  Magit
only makes sense for a git repository, you might want to have C-x v l
(or some other status command) invoke the different "viewer".  If
Magit (e.g.) has other global bindings that make sense for version
control, those also make more sense to put under C-x v.

We already sorta do it with M-., M-, etc where a package can set up
the right variables to get the right tag jumping functions invoked.  

Similarly, for e.g. Bookmark+ (Drew, not suggesting that you rebind
anything :), wouldn't it make better usage if those keybindings are
put under C-x r like the rest of the bookmark bindings?

I am just thinking as a user, where I could expect things to be; and
realise that this might not follow the current Emacs keybinding
policies.  It is strange to reserve a third party key, globally, for
usage where you cannot ever really know what that key does --
shouldn't such a key be up to the user?

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

[Thibaut Verron]

2021-02-10 11:42 UTC+01:00, Alfred M. Szmidt <ams@gnu.org>:
> Since Magit is a VC like mode, wouldn't it make more sense to put it
> under C-x v?  E.g., why cannot Magit rebind C-x v l -- which I guess
> is similar to magit-status or possibly C-x v d.
>
> From a users perspective, making it seemingly a part of VC-mode makes
> more sense than trying to make it a special citizen that needs to take
> C-x g (or whatever) since it would make it hard to use MaGit,
> MaFossil, MaSubersion (last two are fictious) .... together.  Magit
> only makes sense for a git repository, you might want to have C-x v l
> (or some other status command) invoke the different "viewer".  If
> Magit (e.g.) has other global bindings that make sense for version
> control, those also make more sense to put under C-x v.

The problem is that magit-status is both a "visualization" mode,
similar to C-x v d or C-x v l, and a "dispatcher" mode, similar to C-x
v.

An example of usage includes, for example, C-x g c - a c <enter a
commit message> C-c C-c.
This is the equivalent of git commit -a <enter commit message> C-x C-s
C-x k RET.
I can't see a 'vc-commit' function in C-x v, but if there was one, C-x
g c would essentially replace it.
Similarly C-x g P is a vc-push, C-x g F is a (hypothetical) vc-fetch,
C-x g d is a vc-diff, etc.

As such, magit would be better seen as a replacement of the whole vc
keymap than as a part of it. And I don't know if anybody uses both
magit and vc-mode for git version control.
(I occasionally use vc-merge-conflict, but this is not on C-x v.)

But I'm not claiming that rebinding C-x v to magit whenever we are in
a git repository would be a good idea. :)

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

[Alfred M. Szmidt]

   An example of usage includes, for example, C-x g c - a c <enter a
   commit message> C-c C-c.
   This is the equivalent of git commit -a <enter commit message> C-x C-s
   C-x k RET.
   I can't see a 'vc-commit' function in C-x v, but if there was one, C-x
   g c would essentially replace it.

vc-next-action (C-x v v) does exactly that.

   Similarly C-x g P is a vc-push, C-x g F is a (hypothetical) vc-fetch,
   C-x g d is a vc-diff, etc.

C-x v P  vc-push
C-x v +  vc-update
C-x v =  vc-diff

So in the case of Magit, why should there be two bindings for two
version control modes?

   But I'm not claiming that rebinding C-x v to magit whenever we are in
   a git repository would be a good idea. :)

Maybe it is?  If magit is supposed to be a git-only replacement for
vc-mode, maybe that is exactly what it should do.  Or better yet,
integrate better with vc-mode proper. 

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

[Alfred M. Szmidt]

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

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

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

[Thibaut Verron]

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

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

Re: vc-magit mode

[Dmitry Gutov]

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

You've never used Magit, have you?

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

[Eli Zaretskii]

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

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

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

[Alfred M. Szmidt]

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

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

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

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

[Eli Zaretskii]

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

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

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Since Magit is a VC like mode, wouldn't it make more sense to put it
  > under C-x v?  E.g., why cannot Magit rebind C-x v l -- which I guess
  > is similar to magit-status or possibly C-x v d.

I think you are suggesting that the key C-x v could be used both by VC
and by Magit.  That could make sense, if users generally use one or
the other.  There could be a command to switch C-x v to the VC
bindings and a command to switch it to the Magit bindings.

Or perhaps it can be selected by whether the current buffer uses
a vcs other than git.  The options of the global switch could be

* Always use VC
* Always use Magit
* Use VC when the current buffer is stored in a vcs other than git,
  otherwise use Magit.

The third one might need some new low-level keymap facility.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

>   > Since Magit is a VC like mode, wouldn't it make more sense to put it
>   > under C-x v?  E.g., why cannot Magit rebind C-x v l -- which I guess
>   > is similar to magit-status or possibly C-x v d.
>
> I think you are suggesting that the key C-x v could be used both by VC
> and by Magit.  That could make sense, if users generally use one or
> the other.

I use both, as they are good for different things.

I'd prefer to have `C-x v' be vc only to avoid any confusion.

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

[Robert Pluim]

>>>>> On Thu, 11 Feb 2021 08:38:21 -0600, Stefan Kangas <stefankangas@gmail.com> said:

    Stefan> Richard Stallman <rms@gnu.org> writes:
    >> > Since Magit is a VC like mode, wouldn't it make more sense to put it
    >> > under C-x v?  E.g., why cannot Magit rebind C-x v l -- which I guess
    >> > is similar to magit-status or possibly C-x v d.
    >> 
    >> I think you are suggesting that the key C-x v could be used both by VC
    >> and by Magit.  That could make sense, if users generally use one or
    >> the other.

    Stefan> I use both, as they are good for different things.

    Stefan> I'd prefer to have `C-x v' be vc only to avoid any confusion.

+1

vc and Magit are two completely separate things to me (even though I
do use vc to do git stuff as well).

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

[Stefan Monnier]

> vc and Magit are two completely separate things to me (even though I
> do use vc to do git stuff as well).

Most of Magit's commands don't need to be bound globally anyway.
But I think it's best to think of `C-x v` in the same way as for
`lisp/vc`: it's not about the VC package but about the wider notion of
version control.


        Stefan

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

[Alfred M. Szmidt]

   > vc and Magit are two completely separate things to me (even though I
   > do use vc to do git stuff as well).

   Most of Magit's commands don't need to be bound globally anyway.

Then it makes even more sense to just pick a key under C-x v.

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

[Robert Pluim]

>>>>> On Fri, 12 Feb 2021 03:21:49 -0500, "Alfred M. Szmidt" <ams@gnu.org> said:

    >> vc and Magit are two completely separate things to me (even though I
    >> do use vc to do git stuff as well).

    Alfred>    Most of Magit's commands don't need to be bound globally anyway.

    Alfred> Then it makes even more sense to just pick a key under C-x v.

I donʼt follow. Magit is used for magit stuff, from the magit-status
window. If people want to use magit commands from other places, they
can choose their own binding or use the magit recommended ones.

vc is for abstracting away the differences between different version
control systems, why would magit commands need to share a prefix with
it?

Robert

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

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

       >> vc and Magit are two completely separate things to me (even though I
       >> do use vc to do git stuff as well).

       Alfred>    Most of Magit's commands don't need to be bound globally anyway.

       Alfred> Then it makes even more sense to just pick a key under C-x v.

   I donʼt follow. Magit is used for magit stuff, from the magit-status
   window. If people want to use magit commands from other places, they
   can choose their own binding or use the magit recommended ones.

"magit stuff" is version control.

   vc is for abstracting away the differences between different
   version control systems, why would magit commands need to share a
   prefix with it?

'C-x v .' (e.g.) could be bound to an alternative viewer function that
would work depending on the repository, e.g., gitk for those who wish
to use that, kick of a URL action for viewing a fossil repository
using "fossil ui", or whatever.

See how this is a much more general solution to work with _any_
"viewer" (whatever you wanna call magit) than having it take up
keybindings that could be put to a much more general use than a
specialzied one.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > vc is for abstracting away the differences between different version
  > control systems, why would magit commands need to share a prefix with
  > it?

I did not say they "need" to.  But if we are short of places to put
things, putting two things both related to version control, which
people don't use together, on a single key sequence could work well.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Gregory Heytings]

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


>
> Suppose we reserve one key for third-party packages.  Let's refer to 
> that key as C-α, to avoid specifying which key is chosen.
>
> Various packages will set up their own bindings for it.  If you load 
> more than one such package, which package's bindings will you get? How 
> do you get the ones you want?
>

This is something that should be left to packages.  Org-mode would bind, 
say, C-α a, C-α c and C-α l, or perhaps C-α o a, C-α o c and C-α o l; 
Magit would bind C-α g and C-α M-g, or perhaps C-α g g and C-α g f; and so 
forth.  There will be conflicts, of course, but only occasionally, and in 
those cases users would have to do something to resolve the conflict.

>
> Here's an idea.
>
> Have one command you can use to specify which package's bindings C-α 
> will run.  It could be C-α C-α; then individual packages will not give 
> their own bindings for C-α C-α.
>
> So you can type C-α C-α Foopkg RET, then C-α gives you the Foopkg 
> bindings.
>

I'm not sure I understand what you mean.  Would this mean that each time 
you want to use, say, Org-mode you would have to C-α C-α org-mode RET 
before typing C-α c?  If so, I don't think this would work.

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

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

   > Suppose we reserve one key for third-party packages.  Let's refer to 
   > that key as C-α, to avoid specifying which key is chosen.
   >
   > Various packages will set up their own bindings for it.  If you load 
   > more than one such package, which package's bindings will you get? How 
   > do you get the ones you want?

   This is something that should be left to packages.  Org-mode would bind, 
   say, C-α a, C-α c and C-α l, or perhaps C-α o a, C-α o c and C-α o l; 
   Magit would bind C-α g and C-α M-g, or perhaps C-α g g and C-α g f; and so 
   forth.  There will be conflicts, of course, but only occasionally, and in 
   those cases users would have to do something to resolve the conflict.

Wasn't C-? supposed to be a global keybinding?  org-mode speciic
bindings don't make sense outside of org-mode and mode specific
keybindings already have a set that is already reserved for them.  The
issue as I understood it was that there are some modes that have
bindings that make sense in a global context -- e.g., Magit
vs. vc-mode where the specific mode of the buffer doesn't matter.

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

[Gregory Heytings]

>>> Suppose we reserve one key for third-party packages.  Let's refer to 
>>> that key as C-\alpha, to avoid specifying which key is chosen.
>>>
>>> Various packages will set up their own bindings for it.  If you load 
>>> more than one such package, which package's bindings will you get? How 
>>> do you get the ones you want?
>>
>> This is something that should be left to packages.  Org-mode would 
>> bind, say, C-\alpha a, C-\alpha c and C-\alpha l, or perhaps C-\alpha o 
>> a, C-\alpha o c and C-\alpha o l; Magit would bind C-\alpha g and 
>> C-\alpha M-g, or perhaps C-\alpha g g and C-\alpha g f; and so forth. 
>> There will be conflicts, of course, but only occasionally, and in those 
>> cases users would have to do something to resolve the conflict.
>
> Wasn't C-\alpha supposed to be a global keybinding?  org-mode speciic 
> bindings don't make sense outside of org-mode and mode specific 
> keybindings already have a set that is already reserved for them.
>

Org-mode has indeed its own bindings when you are in an org-mode buffer, 
but three of its commands make sense / are designed to be used outside of 
org-mode buffers: org-agenda, org-capture and org-store-link.

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

[Alfred M. Szmidt]

   > Wasn't C-\alpha supposed to be a global keybinding?  org-mode speciic 
   > bindings don't make sense outside of org-mode and mode specific 
   > keybindings already have a set that is already reserved for them.

   Org-mode has indeed its own bindings when you are in an org-mode buffer, 
   but three of its commands make sense / are designed to be used outside of 
   org-mode buffers: org-agenda, org-capture and org-store-link.

So just random thinking, since we have calendar mode, and diary mode.
And those do not have a global binding, why should
org-agenda/org-capture/org-store-link get one?

Or why not put org-store-link under C-x r ?  This seems similar enough
to "bookmarks", capture might even also fit there.  Agenda, too if you
squint I suppose -- or an alias M-x agenda.

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

[Gregory Heytings]

>>> Wasn't C-\alpha supposed to be a global keybinding?  org-mode speciic 
>>> bindings don't make sense outside of org-mode and mode specific 
>>> keybindings already have a set that is already reserved for them.
>>
>> Org-mode has indeed its own bindings when you are in an org-mode 
>> buffer, but three of its commands make sense / are designed to be used 
>> outside of org-mode buffers: org-agenda, org-capture and 
>> org-store-link.
>
> So just random thinking, since we have calendar mode, and diary mode. 
> And those do not have a global binding, why should 
> org-agenda/org-capture/org-store-link get one?
>

Because someone who installs Emacs does not (in general) do that with the 
specific intention of using calendar mode or diary mode, whereas someone 
who installs org-mode does it with the specific intention of using 
org-mode?

That being said, I would not object if Emacs decided to give a global 
binding to some of the built-in apps (calendar, calc, gnus, diary, ...).

>
> Or why not put org-store-link under C-x r ?
>

That would be possible, but there are not many free letters there, and if 
org-mode did this it would take the risk to have the chosen key reclaimed 
by Emacs for another purpose at any time.

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

[Alfred M. Szmidt]

   > Or why not put org-store-link under C-x r ?

   That would be possible, but there are not many free letters there, and if 
   org-mode did this it would take the risk to have the chosen key reclaimed 
   by Emacs for another purpose at any time.

But org-mode is part of Emacs...  

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

[Gregory Heytings]

>>> Or why not put org-store-link under C-x r ?
>>
>> That would be possible, but there are not many free letters there, and 
>> if org-mode did this it would take the risk to have the chosen key 
>> reclaimed by Emacs for another purpose at any time.
>
> But org-mode is part of Emacs...
>

Org-mode is an exception indeed, it is both part of Emacs and an external 
package on Elpa.  As you may have seen, the proposal is not only for 
org-mode, it is for third-party libraries in general.

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

[Drew Adams]

> Org-mode has indeed its own bindings when you are in an org-mode
> buffer, but three of its commands make sense / are designed
> to be used outside of org-mode buffers: org-agenda, org-capture
> and org-store-link.

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

Bug #46087:

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

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

[Drew Adams]

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

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

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

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

Yes, that is indeed one of the points.

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

[Stefan Monnier]

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

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


        Stefan

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > So you can type C-α C-α Foopkg RET, then C-α gives you the Foopkg 
  > > bindings.
  > >

  > I'm not sure I understand what you mean.  Would this mean that each time 
  > you want to use, say, Org-mode you would have to C-α C-α org-mode RET 
  > before typing C-α c?  If so, I don't think this would work.

Org is a collection of major modes, so I don't think it should need to
use the C-α mechanism.  That mechanism would be meant for packages
that need to define a binding for a global prefix key.  Major modes
can simply define local bindings.

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

Perhaps they should be changed into local (major mode) bindings.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Gregory Heytings]

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


>>> So you can type C-α C-α Foopkg RET, then C-α gives you the Foopkg 
>>> bindings.
>>
>> I'm not sure I understand what you mean.  Would this mean that each 
>> time you want to use, say, Org-mode you would have to C-α C-α org-mode 
>> RET before typing C-α c?  If so, I don't think this would work.
>
> Org is a collection of major modes, so I don't think it should need to 
> use the C-α mechanism.  That mechanism would be meant for packages that 
> need to define a binding for a global prefix key.  Major modes can 
> simply define local bindings.
>

Org is indeed a collection of major modes, but three of its commands are 
meant to be bound to global bindings: org-capture, org-agenda, and 
org-store-link.  These commands are intended to be called from anywhere 
else, say from Rmail.  For example, org-capture is similar to (and derived 
from) M-x remember, it lets you store notes without interrupting your work 
flow: while reading a mail in Rmail you can select a part of its text and 
call org-capture, the text you selected will be copied to a new note, you 
can add other information to the note, and the result will be stored in 
your "notes.org" file.

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

[Jean Louis]

* Sean Whitton <spwhitton@spwhitton.name> [2021-02-09 19:45]:
> Hello,
> 
> On Mon 08 Feb 2021 at 02:40PM -08, Eric Abrahamsen wrote:
> 
> > If C-x C-z is already `suspend-frame', do we really need C-z C-z, too?
> 
> As has been mentioned, the thought is that a terminal user who doesn't
> know much about Emacs will probably just hit it a second time if it
> doesn't do what they expect.

I use C-z in shell to stop the job and those jobs usually on my side
impact performance of the computer or performance of the other
job. Imagine the surprise when C-z does not work as expected, will the
user make conclusion to press C-z again after 1 second or after 20 or
30 seconds, and will the data on computer be preserved until that
conclusion arrives? I don't think so.

Removing C-z on console is dangerous for data of computer users IMHO.

Removing C-z on X has less impact on the computer users' data, but
helps user to switch from one frame (iconified) to something else.

Jean

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

[Ulrich Mueller]

>>>>> On Sun, 07 Feb 2021, Gregory Heytings wrote:

> =Proposal=

> It is proposed to repurpose one key, and to reserve it in the key
> binding conventions for third-party packages.  The keys that could be
> reserved for that purpose are:

> Option 1. C-z, with a single exception: "C-z C-z" would be bound to
> "suspend-frame"

Please don't. C-z is bound to "suspend" since a very long time (it's
even mentioned in Craig Finseth's book), and it is one of the few keys
that has an universal meaning on the tty in Unix like systems, across
applications.

Also, it would be a large pain to use anything other than a single key
for this function.

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

[Gregory Heytings]

>> It is proposed to repurpose one key, and to reserve it in the key 
>> binding conventions for third-party packages.  The keys that could be 
>> reserved for that purpose are:
>>
>> Option 1. C-z, with a single exception: "C-z C-z" would be bound to 
>> "suspend-frame"
>
> Please don't. C-z is bound to "suspend" since a very long time (it's 
> even mentioned in Craig Finseth's book), and it is one of the few keys 
> that has an universal meaning on the tty in Unix like systems, across 
> applications.
>
> Also, it would be a large pain to use anything other than a single key 
> for this function.
>

Do you really mean that it is "a large pain" to type "C-z C-z" (three 
keypresses) instead of "C-z" (two keypresses)?  For something you don't do 
frequently?

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

[Ulrich Mueller]

>>>>> On Mon, 08 Feb 2021, Gregory Heytings wrote:

>>> It is proposed to repurpose one key, and to reserve it in the key
>>> binding conventions for third-party packages.  The keys that could
>>> be reserved for that purpose are:
>>> 
>>> Option 1. C-z, with a single exception: "C-z C-z" would be bound to
>>> "suspend-frame"
>> 
>> Please don't. C-z is bound to "suspend" since a very long time (it's
>> even mentioned in Craig Finseth's book), and it is one of the few
>> keys that has an universal meaning on the tty in Unix like systems,
>> across applications.
>> 
>> Also, it would be a large pain to use anything other than a single
>> key for this function.

> Do you really mean that it is "a large pain" to type "C-z C-z" (three
> keypresses) instead of "C-z" (two keypresses)? For something you don't
> do frequently?

I'd say that at least on a tty I use C-z more frequently than several
other control keys.

How about C-\ or C-^? Historically these were used as substitutes for
C-s and C-q when editing via serial lines (and there's still a function
enable-flow-control that activates it). Certainly that's no longer a
frequent use case?

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

[Gregory Heytings]

>> Do you really mean that it is "a large pain" to type "C-z C-z" (three 
>> keypresses) instead of "C-z" (two keypresses)? For something you don't 
>> do frequently?
>
> I'd say that at least on a tty I use C-z more frequently than several 
> other control keys.
>

So do I, but that still doesn't make it "a large pain" to type "C-z C-z" 
instead of "C-z", I guess.

>
> How about C-\ or C-^?
>

I did consider to include C-\ in the options, but \ is hard to type on 
most keyboards: C and \ are the two most distant keys on the most 
widespread keyboard layout (QWERTY), on other keyboards \ requires 
pressing Shift or AltGr, ...  A letter would be much better.

C-^ is clearly not an option, it is way too hard to type even with the 
QWERTY layout (C-S-6).

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

[Sean Whitton]

Hello,

On Mon 08 Feb 2021 at 10:37PM +01, Ulrich Mueller wrote:

> How about C-\ or C-^? Historically these were used as substitutes for
> C-s and C-q when editing via serial lines (and there's still a function
> enable-flow-control that activates it). Certainly that's no longer a
> frequent use case?

C-\ is used to set the input method.  But we could move that
functionality to C-^, and then give up C-\ to third party packages.

-- 
Sean Whitton

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

[Gregory Heytings]

>> How about C-\ or C-^? Historically these were used as substitutes for 
>> C-s and C-q when editing via serial lines (and there's still a function 
>> enable-flow-control that activates it). Certainly that's no longer a 
>> frequent use case?
>
> C-\ is used to set the input method.  But we could move that 
> functionality to C-^, and then give up C-\ to third party packages.
>

Except that \ is hard to type on most keyboards: C and \ are the two most 
distant keys on the most widespread keyboard layout (QWERTY), and on other 
keyboards \ requires pressing Shift or AltGr.  Not exactly an appealing 
prefix.

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

[Ulrich Mueller]

>>>>> On Tue, 09 Feb 2021, Gregory Heytings wrote:

>>> How about C-\ or C-^? Historically these were used as substitutes
>>> for C-s and C-q when editing via serial lines (and there's still a
>>> function enable-flow-control that activates it). Certainly that's
>>> no longer a frequent use case?
>> 
>> C-\ is used to set the input method.  But we could move that
>> functionality to C-^, and then give up C-\ to third party packages.

> Except that \ is hard to type on most keyboards: C and \ are the two
> most distant keys on the most widespread keyboard layout (QWERTY), and
> on other keyboards \ requires pressing Shift or AltGr.  Not exactly an
> appealing prefix.

The same could be said for C-o or M-o. And if you care about non-QWERTY
layouts, C-z on a German QWERTZ keyboard isn't much better.

(Also I wonder, aren't Shift, Ctrl, and Alt keys meant to be used
crosswise, i.e., left key for the right half of the keyboard, and vice
versa? For example, how do you type C-b or C-t?)

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

[Gregory Heytings]

>>> C-\ is used to set the input method.  But we could move that 
>>> functionality to C-^, and then give up C-\ to third party packages.
>>
>> Except that \ is hard to type on most keyboards: C and \ are the two 
>> most distant keys on the most widespread keyboard layout (QWERTY), and 
>> on other keyboards \ requires pressing Shift or AltGr.  Not exactly an 
>> appealing prefix.
>
> The same could be said for C-o or M-o. And if you care about non-QWERTY 
> layouts, C-z on a German QWERTZ keyboard isn't much better.
>

At least these are letters, which do not require pressing Shift or AltGr 
anywhere.  Nothing is perfect, it's a practical problem, and "o" and "z" 
are the only letters that have a non-zero chance to be repurposed.

>
> (Also I wonder, aren't Shift, Ctrl, and Alt keys meant to be used 
> crosswise, i.e., left key for the right half of the keyboard, and vice 
> versa? For example, how do you type C-b or C-t?)
>

That depends on your keyboard, not all keyboards have two Ctrl keys and 
two Meta/Alt keys.  I remapped Caps Lock to Ctrl, and have my left pinkie 
almost always resting on it.

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

[Thibaut Verron]

2021-02-09 18:19 UTC+01:00, Gregory Heytings <gregory@heytings.org>:
>
>>> How about C-\ or C-^? Historically these were used as substitutes for
>>> C-s and C-q when editing via serial lines (and there's still a function
>>> enable-flow-control that activates it). Certainly that's no longer a
>>> frequent use case?
>>
>> C-\ is used to set the input method.  But we could move that
>> functionality to C-^, and then give up C-\ to third party packages.
>>
>
> Except that \ is hard to type on most keyboards: C and \ are the two most
> distant keys on the most widespread keyboard layout (QWERTY), and on other
> keyboards \ requires pressing Shift or AltGr.

I don't quite get how you reach that conclusion about the qwerty keyboard.

On my ISO102 qwerty keyboard, \ is diagonally adjacent to left control
(regardless of whether it's at its original position or on capslock),
and there is another \ left of RET, so two keys above, one left of
right control.

With an ANSI keyboard, it's only available on one key, which is 3 keys
above right control.

So in both cases, I don't think it qualifies as "the most distant key"
from control. To the contrary, I'd say that it is too close to it to
be comfortable to type if you don't use different hands for modifier
and key.

And while \ indeed is a pain to type on non-qwerty layouts, on an
azerty keyboard, the corresponding keys are < and *, both of which are
free with a C- modifier.
On a qwertz it's < and $, which again are free with a C- modifier.

(Those are the keyboards I can look at here, I don't know how it generalizes.)

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

[Gregory Heytings]

>> Except that \ is hard to type on most keyboards: C and \ are the two 
>> most distant keys on the most widespread keyboard layout (QWERTY), and 
>> on other keyboards \ requires pressing Shift or AltGr.
>
> I don't quite get how you reach that conclusion about the qwerty 
> keyboard.
>
> On my ISO102 qwerty keyboard, \ is diagonally adjacent to left control 
> (regardless of whether it's at its original position or on capslock), 
> and there is another \ left of RET, so two keys above, one left of right 
> control.
>
> With an ANSI keyboard, it's only available on one key, which is 3 keys 
> above right control.
>

This is diverging more and more from the proposal, but: on smaller 
keyboards (laptops) there is typically only one control key (on the bottom 
left) and only \ key (near the right top).

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

[Thibaut Verron]

2021-02-09 20:16 UTC+01:00, Gregory Heytings <gregory@heytings.org>:
>
>>> Except that \ is hard to type on most keyboards: C and \ are the two
>>> most distant keys on the most widespread keyboard layout (QWERTY), and
>>> on other keyboards \ requires pressing Shift or AltGr.
>>
>> I don't quite get how you reach that conclusion about the qwerty
>> keyboard.
>>
>> On my ISO102 qwerty keyboard, \ is diagonally adjacent to left control
>> (regardless of whether it's at its original position or on capslock),
>> and there is another \ left of RET, so two keys above, one left of right
>> control.
>>
>> With an ANSI keyboard, it's only available on one key, which is 3 keys
>> above right control.
>>
>
> This is diverging more and more from the proposal, but: on smaller
> keyboards (laptops) there is typically only one control key (on the bottom
> left) and only \ key (near the right top).
>

I cannot remember ever laying my hands on a laptop with only one
control key, but that may be one more of those ISO vs ANSI things.

At any rate, it's far easier to type C-\ with the left hand on control
and right hand on \ than both with the right hand. The fact that your
left control is on capslock (mine is, too) shouldn't make a
difference: left pinky on control/capslock, right pinky on \.

Do you also find C-ret or C-backspace hard to type?

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

[Gregory Heytings]

>
> Do you also find C-ret or C-backspace hard to type?
>

C-\ or M-\, or C-RET or M-RET, are perhaps not "hard to type" by 
themselves on keyboards that do not require pressing another modifier, but 
as a prefix, followed by another letter, or C-letter, or M-letter, they 
would.  You have to move your hands too much.  It can't be an appealing 
solution for third-party libraries.

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

[Stefan Monnier]

> This is diverging more and more from the proposal, but: on smaller keyboards
> (laptops) there is typically only one control key (on the bottom left) and
> only \ key (near the right top).

And I don't own a "non-small keyboard" any more, and judging from
people around me, I'm far from the only one.


        Stefan

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

[Gregory Heytings]

>
> And while \ indeed is a pain to type on non-qwerty layouts, on an azerty 
> keyboard, the corresponding keys are < and *, both of which are free 
> with a C- modifier. On a qwertz it's < and $, which again are free with 
> a C- modifier.
>

I forgot to mention that these keys are indeed free, but do not work in a 
terminal.

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

[Sean Whitton]

Hello,

On Tue 09 Feb 2021 at 05:19PM GMT, Gregory Heytings wrote:

>>> How about C-\ or C-^? Historically these were used as substitutes for
>>> C-s and C-q when editing via serial lines (and there's still a function
>>> enable-flow-control that activates it). Certainly that's no longer a
>>> frequent use case?
>>
>> C-\ is used to set the input method.  But we could move that
>> functionality to C-^, and then give up C-\ to third party packages.
>>
>
> Except that \ is hard to type on most keyboards: C and \ are the two most
> distant keys on the most widespread keyboard layout (QWERTY), and on other
> keyboards \ requires pressing Shift or AltGr.  Not exactly an appealing
> prefix.

Hmm, if you're using two hands for the C and the \ and you're on QWERTY
then it's not too bad.

Should we be trying to take into account other layouts, given that most
of Emacs' default bindings are designed for a keyboard which doesn't
even exist anymore (Space Cadet)?

ISTM that we are only rarely going to find options which are optimum for
all layouts at once, so maybe we should expect users of those layouts to
move hard things around (and that moving around could be included in
Emacs).

-- 
Sean Whitton

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

[Philip K.]

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

Gregory Heytings <gregory@heytings.org> writes:

>>> When such packages need to bind a command to a key, they can (1)
>>> either suggest users to bind it to a key reserved for users (for
>>> example, org-mode suggests to globally bind "C-c c" to
>>> org-capture), or (2) bind it to a key currently unused by Emacs
>>> (for example, Magit binds "C-x g" to magit-status in buffers
>>> visiting a file in a Git repository).
>>>
>>> Neither of these solutions are optimal: (1) requires an explicit
>>> configuration by the user, something which might confuse newcomers,
>>> and which other users might not want to do because they already use
>>> the keys reserved for users for other purposes, and (2) might
>>> conflict with the evolution of Emacs when one or more commands are
>>> bound to a yet unused key.
>>
>> I don't think this is a good idea, because situation (1) is good,
>> actually.  Configuring a package, that provides a command as it's 
>> interface, should be done by binding it to a key reserved for
>> users. Just like how configuring a minor mode is done by adding it
>> to a hook or a major mode by adding it to auto-mode-alist.
>>
>
> Situation (1) might be good in theory, it was probably good twenty
> years ago, but at least nowadays it is, in practice, not good.  What
> most users do is that they install third-party packages through their
> distro package manager, or through Elpa or Melpa, and they just expect
> / would like it to work.  That's what would happen when you install
> extension packages in most (if not all) other software (editors,
> browsers, ...): you don't have to manually fiddle with configuration
> files to make them work.

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

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

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

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

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

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

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

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

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

-- 
	Philip K.

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

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

[Gregory Heytings]

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

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

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

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

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

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

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

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

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

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