Proposal: new default bindings for winner and windmove

Proposal: new default bindings for winner and windmove

[Daniel Colascione]

Today, winner binds C-c LEFT  and C-c RIGHT for window configuration 
undo and redo, respectively. This set of bindings has three problems:

  1) the bindings occupy binding space on important keys, LEFT and 
RIGHT, for functions that are rarely used,

2) the winner binding space isn't logically connected to window 
management, and

3) the bindings don't work on terminals without LEFT and RIGHT.

How about we set up these bindings instead?

C-x 4 C-/ winner-undo

M-- C-x 4 C-/ winner-redo

This way, a winner undo has the same binding as editing undo, but under 
C-x 4, which means window management stuff.

(Also: is there any reason we shouldn't enable winner by default?)

Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and 
DWIM for people automatically, enabled by default.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Daniel Colascione <dancol@dancol.org>
> Date: Sat, 21 Aug 2021 12:10:16 -0700
> 
> Today, winner binds C-c LEFT  and C-c RIGHT for window configuration 
> undo and redo, respectively. This set of bindings has three problems:
> 
>   1) the bindings occupy binding space on important keys, LEFT and 
> RIGHT, for functions that are rarely used,
> 
> 2) the winner binding space isn't logically connected to window 
> management, and
> 
> 3) the bindings don't work on terminals without LEFT and RIGHT.
> 
> How about we set up these bindings instead?

I'm actually surprised they have key bindings.  How frequently do you
undo/redo window configuration changes?

But I don't use winner, so maybe I'm missing something.

> (Also: is there any reason we shouldn't enable winner by default?)

Doesn't the tab bar offer a similar functionality?

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On 8/21/21 12:23 PM, Eli Zaretskii wrote:
>> From: Daniel Colascione <dancol@dancol.org>
>> Date: Sat, 21 Aug 2021 12:10:16 -0700
>>
>> Today, winner binds C-c LEFT  and C-c RIGHT for window configuration
>> undo and redo, respectively. This set of bindings has three problems:
>>
>>    1) the bindings occupy binding space on important keys, LEFT and
>> RIGHT, for functions that are rarely used,
>>
>> 2) the winner binding space isn't logically connected to window
>> management, and
>>
>> 3) the bindings don't work on terminals without LEFT and RIGHT.
>>
>> How about we set up these bindings instead?
> I'm actually surprised they have key bindings.  How frequently do you
> undo/redo window configuration changes?

I do is pretty often actually --- winner's undo history acts as a task 
stack. When I'm in the middle of working on something and temporarily 
want to do some other thing that changes window configuration --- for 
example, using calc or running some test in a shell buffer --- and I 
want just go back to what I was doing, restoring the window 
configuration is useful. Sure, I can save the window configuration in a 
register instead, but doing that requires forethought and winner doesn't.

>> (Also: is there any reason we shouldn't enable winner by default?)
> Doesn't the tab bar offer a similar functionality?

I don't use the tab bar. I don't like that it takes up screen real 
estate, and I prefer other ways of working with windows.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Daniel Colascione <dancol@dancol.org>
> Date: Sat, 21 Aug 2021 12:27:44 -0700
> 
> >> (Also: is there any reason we shouldn't enable winner by default?)
> > Doesn't the tab bar offer a similar functionality?
> 
> I don't use the tab bar. I don't like that it takes up screen real 
> estate, and I prefer other ways of working with windows.

AFAIR, tab-bar functionality can be configured not to show the tab bar
itself?  (Not that I'm selling the tab bar...)

Re: Proposal: new default bindings for winner and windmove

[Juri Linkov]

>> > Doesn't the tab bar offer a similar functionality?
>>
>> I don't use the tab bar. I don't like that it takes up screen real
>> estate, and I prefer other ways of working with windows.
>
> AFAIR, tab-bar functionality can be configured not to show the tab bar
> itself?

Whereas tab-bar-history-mode can be used independently without
the tab bar, it's intended for the users of tab-bar-mode.

Re: Proposal: new default bindings for winner and windmove

[Clément Pit-Claudel]

On 8/21/21 3:23 PM, Eli Zaretskii wrote:
> I'm actually surprised they have key bindings.  How frequently do you
> undo/redo window configuration changes?

I use it very frequently, after using things like VC or Proof general or many others that change the window configuration.

I like the current bindings very much, FWIW.

Re: Proposal: new default bindings for winner and windmove

[Kaushal Modi]

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

On Sat, Aug 21, 2021 at 3:43 PM Clément Pit-Claudel <cpitclaudel@gmail.com>
wrote:

> On 8/21/21 3:23 PM, Eli Zaretskii wrote:
> > I'm actually surprised they have key bindings.  How frequently do you
> > undo/redo window configuration changes?
>
> I use it very frequently, after using things like VC or Proof general or
> many others that change the window configuration.
>
> I like the current bindings very much, FWIW.
>


+1

I use the default windmove bindings daily.

[-- Attachment #2: Type: text/html, Size: 848 bytes --]

Re: Proposal: new default bindings for winner and windmove

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Daniel Colascione <dancol@dancol.org>
>> Date: Sat, 21 Aug 2021 12:10:16 -0700
>> 
>> Today, winner binds C-c LEFT  and C-c RIGHT for window configuration 
>> undo and redo, respectively. This set of bindings has three problems:
>> 
>>   1) the bindings occupy binding space on important keys, LEFT and 
>> RIGHT, for functions that are rarely used,
>> 
>> 2) the winner binding space isn't logically connected to window 
>> management, and
>> 
>> 3) the bindings don't work on terminals without LEFT and RIGHT.
>> 
>> How about we set up these bindings instead?
>
> I'm actually surprised they have key bindings.  How frequently do you
> undo/redo window configuration changes?
You obviously don't need to call help functions as often as I :). It is
handy to restore back windows after some help lookup, or after something
else opened a window that is left over. Compile log for example. I have
my binding on C-v u and C-v r, but it is mostly C-v u I use form time to
time. 

Maybe I am just n00b myself, maybe you have better workflow.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: Daniel Colascione <dancol@dancol.org>,  emacs-devel@gnu.org
> Date: Sat, 21 Aug 2021 22:20:22 +0200
> 
> > I'm actually surprised they have key bindings.  How frequently do you
> > undo/redo window configuration changes?
> You obviously don't need to call help functions as often as I :).

That's not true: contrary to the popular belief, I don't keep all of
Emacs in my memory.  I actually use Help functions very frequently,
which is why one of my frames always has a Help window open.  I simply
don't delete that window, because I know I'll need it again in a
moment.

> It is handy to restore back windows after some help lookup, or after
> something else opened a window that is left over. Compile log for
> example. I have my binding on C-v u and C-v r, but it is mostly C-v
> u I use form time to time.

My solution to the "window configuration issue" is to keep several
frames, one each for different tasks.  Each frame has windows arranged
as appropriate for that task, and that configuration rarely if ever
changes.  Of course, if someone has a lot of concurrent tasks and a
screen that is not large enough, they can run out of screen estate, so
scalability could be an issue.  But not for me.

Re: Proposal: new default bindings for winner and windmove

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: Daniel Colascione <dancol@dancol.org>,  emacs-devel@gnu.org
>> Date: Sat, 21 Aug 2021 22:20:22 +0200
>> 
>> > I'm actually surprised they have key bindings.  How frequently do you
>> > undo/redo window configuration changes?
>> You obviously don't need to call help functions as often as I :).
>
> That's not true: contrary to the popular belief, I don't keep all of
> Emacs in my memory.  I actually use Help functions very frequently,
I know I have seen you write this in other occasions, but some myths are
hard to debunk!

> which is why one of my frames always has a Help window open.  I simply
> don't delete that window, because I know I'll need it again in a
> moment.
You have reminded me of another from my todo wish-list. I wanted to
configure help to not open new window every time, because I also had
some thoughts of keeping it open all the time. Problem with help buffer
is that it pops up at unnexpected places, and I am looking all over the
place to see where did it popped now. I wanted it mostly for this reason
at same spot. winner-undo was a quick way to restore the state.

I have just added help, helpful, aproppos and few others to
display-buffer-alist and configured them to use same window.

>> It is handy to restore back windows after some help lookup, or after
>> something else opened a window that is left over. Compile log for
>> example. I have my binding on C-v u and C-v r, but it is mostly C-v
>> u I use form time to time.
>
> My solution to the "window configuration issue" is to keep several
> frames, one each for different tasks.  Each frame has windows arranged
> as appropriate for that task, and that configuration rarely if ever
> changes.  Of course, if someone has a lot of concurrent tasks and a
> screen that is not large enough, they can run out of screen estate, so
> scalability could be an issue.  But not for me.

I only use different frame for Gnus since it seems to expect its own
frame and I try to run everything else in another frame, two window pane
is my favourite. But maybe it is better to have a frame with a dedicated
layout for a task.

Thank you for sharing.

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> You have reminded me of another from my todo wish-list. I wanted to
> configure help to not open new window every time, because I also had
> some thoughts of keeping it open all the time. 

I use a dedicated *Help* frame.  More or less this:

(add-to-list
  'special-display-buffer-names
  (list "*Help*" '1on1-display-*Help*-frame
        ;; ... frame-parameters ...
        ))

(defun 1on1-display-*Help*-frame (buf &optional args)
  (let ((return-window
         (select-window (funcall special-display-function buf args))))
    (raise-frame)
    return-window))

Of course that doesn't mean I "keep it open" all the time.
I iconify (thumbify) it, delete it, ... whatever, whenever.

Re: Proposal: new default bindings for winner and windmove

[Phil Sainty]

On 2021-08-22 07:23, Eli Zaretskii wrote:
> I'm actually surprised they have key bindings.  How frequently do you
> undo/redo window configuration changes?
> 
> But I don't use winner, so maybe I'm missing something.

Extremely frequently, for reverting both intentional and
unintentional changes; often repeatedly just to get back
to some recent previous state after a sequence of changes.

It trivially lets me maximise any window and then jump
back to the previous window split, for instance; and if
anything displays a buffer that I only need temporarily,
it's my go-to for returning to how things were before
that happened.


-Phil

Re: Proposal: new default bindings for winner and windmove

[Teemu Likonen]

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

* 2021-08-21 22:23:21+0300, Eli Zaretskii wrote:

>> From: Daniel Colascione <dancol@dancol.org>
>> Today, winner binds C-c LEFT  and C-c RIGHT for window configuration 
>> undo and redo, respectively.

> I'm actually surprised they have key bindings.  How frequently do you
> undo/redo window configuration changes?
>
> But I don't use winner, so maybe I'm missing something.

Like others have said: very often. Many commands split windows or change
the window configuration other ways. Command "C-c <left>" (winner-undo)
is about the fastest possible way to get back to previous window
configurations. The main point of winner-mode is the automatically saved
history of window configurations.

>> (Also: is there any reason we shouldn't enable winner by default?)
>
> Doesn't the tab bar offer a similar functionality?

Not in the sense of history. With tab-bar-mode or manual saving of
window configuration a user must plan window changes before.

But the original question was about new default bindings. I think "C-x
4" keymap would be a logical place if the original "C-c <left>" and "C-c
<right>" are a problem.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

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

Re: Proposal: new default bindings for winner and windmove

[Teemu Likonen]

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

* 2021-08-22 08:13:30+0300, Teemu Likonen wrote:

> * 2021-08-21 22:23:21+0300, Eli Zaretskii wrote:
>> Doesn't the tab bar offer a similar functionality?
>
> Not in the sense of history. With tab-bar-mode or manual saving of
> window configuration a user must plan window changes before.

Actually tab-bar-history-mode does about the same thing that I like
about winner-undo and winner-redo. Maybe I'll try tab-bar-mode and
tab-bar-history-mode for a while if I like them better than winner-mode.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

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

Re: Proposal: new default bindings for winner and windmove

[Arthur Miller]

Daniel Colascione <dancol@dancol.org> writes:

> Today, winner binds C-c LEFT  and C-c RIGHT for window configuration undo and
> redo, respectively. This set of bindings has three problems:
>
>  1) the bindings occupy binding space on important keys, LEFT and RIGHT, for
> functions that are rarely used,
>
> 2) the winner binding space isn't logically connected to window management, and
>
> 3) the bindings don't work on terminals without LEFT and RIGHT.
>
> How about we set up these bindings instead?
>
> C-x 4 C-/ winner-undo
>
> M-- C-x 4 C-/ winner-redo
>
> This way, a winner undo has the same binding as editing undo, but under C-x 4,
> which means window management stuff.
>
> (Also: is there any reason we shouldn't enable winner by default?)
Personally I don't care which bindings are used by default, because I
rebind most of stuff anyway, but I do think it should be on by default.

> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM for
> people automatically, enabled by default.

Same as above.

Re: Proposal: new default bindings for winner and windmove

[Juri Linkov]

> How about we set up these bindings instead?
>
> C-x 4 C-/ winner-undo
>
> M-- C-x 4 C-/ winner-redo
>
> This way, a winner undo has the same binding as editing undo, but under C-x
> 4, which means window management stuff.
>
> (Also: is there any reason we shouldn't enable winner by default?)
>
> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
> for people automatically, enabled by default.

This reminds the recent development of the context menu.
The idea to enable the context menu by default was nice
where quickly clicking mouse-3 will retain its current functionality
of operating on the region, but after a delay to pop up the menu.
But in practice such artificial delay is a hassle - no one would have
patience to wait even half a second until the menu finally appears.

The same applies to longer keybindings.  It would be nice to provide the
default long keybindings, but they are unusable for frequent usage because
require more time to type the keys.  So maybe longer keybindings could be
set only to "advertise" the availability of such feature until the package
is loaded and defines shorter keys.

Re: Proposal: new default bindings for winner and windmove

[Arthur Miller]

Juri Linkov <juri@linkov.net> writes:

>> How about we set up these bindings instead?
>>
>> C-x 4 C-/ winner-undo
>>
>> M-- C-x 4 C-/ winner-redo
>>
>> This way, a winner undo has the same binding as editing undo, but under C-x
>> 4, which means window management stuff.
>>
>> (Also: is there any reason we shouldn't enable winner by default?)
>>
>> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
>> for people automatically, enabled by default.
>
> This reminds the recent development of the context menu.
> The idea to enable the context menu by default was nice
> where quickly clicking mouse-3 will retain its current functionality
> of operating on the region, but after a delay to pop up the menu.
> But in practice such artificial delay is a hassle - no one would have
> patience to wait even half a second until the menu finally appears.
>
> The same applies to longer keybindings.  It would be nice to provide the
> default long keybindings, but they are unusable for frequent usage because
> require more time to type the keys.  So maybe longer keybindings could be
> set only to "advertise" the availability of such feature until the package
> is loaded and defines shorter keys.

I think "Advertise a feature" is a good term. That is why I said, I
don't care about bindings.

Bu the way, text undo seems to be bound to several key beyndings,
amongst them C-x u and C-x U:

"C-x u (translated from C-x U) runs the command undo (found in global-map), which
is an interactive native compiled Lisp function in ‘simple.el’."

What about geaving C-x U to winner undo. That would make C-x u work on
text, and C-x U work on windows. Kind of similar logic but simpler
binding.

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On 8/22/21 1:37 AM, Juri Linkov wrote:
>> How about we set up these bindings instead?
>>
>> C-x 4 C-/ winner-undo
>>
>> M-- C-x 4 C-/ winner-redo
>>
>> This way, a winner undo has the same binding as editing undo, but under C-x
>> 4, which means window management stuff.
>>
>> (Also: is there any reason we shouldn't enable winner by default?)
>>
>> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
>> for people automatically, enabled by default.
> This reminds the recent development of the context menu.
> The idea to enable the context menu by default was nice
> where quickly clicking mouse-3 will retain its current functionality
> of operating on the region, but after a delay to pop up the menu.
> But in practice such artificial delay is a hassle - no one would have
> patience to wait even half a second until the menu finally appears.
>
> The same applies to longer keybindings.  It would be nice to provide the
> default long keybindings, but they are unusable for frequent usage because
> require more time to type the keys.  So maybe longer keybindings could be
> set only to "advertise" the availability of such feature until the package
> is loaded and defines shorter keys.

Isn't this advertisement implicit in the whole structure of Emacs? You 
can take *any* command and bind it to whatever shortcut-key you want. 
That the command exists at all is an advertisement.

(And if we're talking about long annoying default advertisements, C-u 
C-x ~ for going to the previous error is more annoying.)

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

> M-- C-x 4 C-/ winner-redo
>
> This way, a winner undo has the same binding as editing undo, but under C-x
> 4, which means window management stuff.
>
> (Also: is there any reason we shouldn't enable winner by default?)

IIUC these features somewhat overlap with the (new) features introduced
with the (frame-level) tab-bar, so it would likely be good to try and
integrate them better.

As for a key-binding, `C-x 4` might be a good prefix for it, tho note
that `C-x 5` is also a good choice (since winner does not operate on
a window but on the windows within a frame).

Count me as a vote in favor of using a key-binding like the one you suggest.

> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
> for people automatically, enabled by default.

That sounds even better (and we could have similar commands in `C-x 5`
to select frames based on their location on the screen).


        Stefan

Re: Proposal: new default bindings for winner and windmove

[Lars Ingebrigtsen]

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

>> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
>> for people automatically, enabled by default.
>
> That sounds even better (and we could have similar commands in `C-x 5`
> to select frames based on their location on the screen).

Sounds good to me, too -- we could bind those by default.

But I don't think we can change the C-c <left> etc bindings for those
that enable winner-mode explicitly -- I think that's likely to be very
annoying for those users.

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

Re: Proposal: new default bindings for winner and windmove

[Bozhidar Batsov]

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

I also think it's a bad idea to change some keybindings, especially if we know that some people like them and have been using them for ages. (I've gotten plenty of bad feedback for the users of my Emacs packages for doing such changes in the past) Changes to keybindings are considered breaking changes by many people and those should be avoided. 

On Mon, Aug 23, 2021, at 1:01 AM, Lars Ingebrigtsen wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
> >> for people automatically, enabled by default.
> >
> > That sounds even better (and we could have similar commands in `C-x 5`
> > to select frames based on their location on the screen).
> 
> Sounds good to me, too -- we could bind those by default.
> 
> But I don't think we can change the C-c <left> etc bindings for those
> that enable winner-mode explicitly -- I think that's likely to be very
> annoying for those users.
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
> 
> 

[-- Attachment #2: Type: text/html, Size: 1708 bytes --]

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

>> But I don't think we can change the C-c <left> etc bindings for those
>> that enable winner-mode explicitly -- I think that's likely to be very
>> annoying for those users.

We can expose winner commands by default under some appropriate
key-binding without it affecting the result of people who enable
`winner-mode`.  Basically `winner-mode` would then just be a backward
compatibility minor mode that provides the feature under the old
key-bindings.

> I also think it's a bad idea to change some keybindings, especially if we
> know that some people like them and have been using them for ages. (I've
> gotten plenty of bad feedback for the users of my Emacs packages for doing
> such changes in the past) Changes to keybindings are considered breaking
> changes by many people and those should be avoided.

We try to keep the "old way" working or provide a one-liner recovering
the "old way", indeed.
That doesn't prevent changes (nor does it prevent complaints,
admittedly, since you can't satisfy everyone every time).


        Stefan

Re: Proposal: new default bindings for winner and windmove

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

This seems like the sort of issue for which polling the users would
be useful.

-- 
Dr Richard Stallman (https://stallman.org)
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: new default bindings for winner and windmove

[Stefan Monnier]

A few years ago, Daniel suggested:
> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
> for people automatically, enabled by default.

AFAICT we still don't actually provide any keybindings for the windmove
commands by default.  Did I miss a controversy about that, or did it
just fall through the cracks?

[ I mean, I assume there are different opinions about which set of keybindings
  is the best, but it seems to me that it should not be that hard to
  find a default set of keybindings that's better than no keybindings
  at all.  ]


        Stefan

Re: Proposal: new default bindings for winner and windmove

[Stefan Kangas]

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

> A few years ago, Daniel suggested:
>> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
>> for people automatically, enabled by default.
>
> AFAICT we still don't actually provide any keybindings for the windmove
> commands by default.  Did I miss a controversy about that, or did it
> just fall through the cracks?

FWIW, I don't remember any controversy either, so my guess is that it
just fell through the cracks.

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Stefan and Stefan.

On Fri, Jun 21, 2024 at 15:39:09 -0500, Stefan Kangas wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > A few years ago, Daniel suggested:
> >> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
> >> for people automatically, enabled by default.
> >
> > AFAICT we still don't actually provide any keybindings for the windmove
> > commands by default.  Did I miss a controversy about that, or did it
> > just fall through the cracks?

> FWIW, I don't remember any controversy either, so my guess is that it
> just fell through the cracks.

I would be against using C-x 4 <arrow keys> or C-x 5 <arrow-keys> for
windmove (or anything else) by default.  Key sequences with arrow keys
are too few, and too precious, to use for anything not critically
important.

windmove is not critically important.  Either it isn't used at all by a
user (likely most users), or it is used all the time (by a small number
of users).  In the latter case, the user will already have bound the
commands to key sequences, since they are not useful called from M-x.

It wasn't so long ago that we were removing default key bindings so as
to free them up for other uses.  I don't think there's any reason to
reverse that policy for windmove.  It just isn't important enough.

There will be users who've bound these key bindings for their own uses.
Let's not mess these users around.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 23, 2024 6:05:13 AM EDT, Alan Mackenzie <acm@muc.de> wrote:
>Hello, Stefan and Stefan.
>
>On Fri, Jun 21, 2024 at 15:39:09 -0500, Stefan Kangas wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> > A few years ago, Daniel suggested:
>> >> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
>> >> for people automatically, enabled by default.
>> >
>> > AFAICT we still don't actually provide any keybindings for the windmove
>> > commands by default.  Did I miss a controversy about that, or did it
>> > just fall through the cracks?
>
>> FWIW, I don't remember any controversy either, so my guess is that it
>> just fell through the cracks.
>
>I would be against using C-x 4 <arrow keys> or C-x 5 <arrow-keys> for
>windmove (or anything else) by default.  Key sequences with arrow keys
>are too few, and too precious, to use for anything not critically
>important.
>
>windmove is not critically important.  Either it isn't used at all by a
>user (likely most users), or it is used all the time (by a small number
>of users).  In the latter case, the user will already have bound the
>commands to key sequences, since they are not useful called from M-x.
>
>It wasn't so long ago that we were removing default key bindings so as
>to free them up for other uses.  I don't think there's any reason to
>reverse that policy for windmove.  It just isn't important enough.
>
>There will be users who've bound these key bindings for their own uses.
>Let's not mess these users around.

The arrow keys don't have any meaning after C-x 4 today, and the meaning I've been wanting to give them is useful and logical. I've been using the arrow key setup for years locally and it works very well. It really does make window management much less annoying, and it's not like we're going to use the arrow keys for anything else under C-x 4.


As for windmove being used by users --- well, wouldn't it be nice if we had metrics like other modern software projects? But that aside, even if windmove is sparsely used today, might that be because it's inconvenient to use without bindings? Your argument is a general purpose argument against having default bindings, isn't it? Key bindings are precious, and we shouldn't waste them on unimportant things, and if the things were important, we wouldn't need default key bindings for them anyway because users would have already created their own. The argument seems a bit circular to me.

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Daniel.

On Sun, Jun 23, 2024 at 07:14:25 -0400, Daniel Colascione wrote:


> On June 23, 2024 6:05:13 AM EDT, Alan Mackenzie <acm@muc.de> wrote:
> >Hello, Stefan and Stefan.

> >On Fri, Jun 21, 2024 at 15:39:09 -0500, Stefan Kangas wrote:
> >> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >> > A few years ago, Daniel suggested:
> >> >> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
> >> >> for people automatically, enabled by default.

> >> > AFAICT we still don't actually provide any keybindings for the windmove
> >> > commands by default.  Did I miss a controversy about that, or did it
> >> > just fall through the cracks?

> >> FWIW, I don't remember any controversy either, so my guess is that it
> >> just fell through the cracks.

> >I would be against using C-x 4 <arrow keys> or C-x 5 <arrow-keys> for
> >windmove (or anything else) by default.  Key sequences with arrow keys
> >are too few, and too precious, to use for anything not critically
> >important.

> >windmove is not critically important.  Either it isn't used at all by a
> >user (likely most users), or it is used all the time (by a small number
> >of users).  In the latter case, the user will already have bound the
> >commands to key sequences, since they are not useful called from M-x.

> >It wasn't so long ago that we were removing default key bindings so as
> >to free them up for other uses.  I don't think there's any reason to
> >reverse that policy for windmove.  It just isn't important enough.

> >There will be users who've bound these key bindings for their own uses.
> >Let's not mess these users around.

> The arrow keys don't have any meaning after C-x 4 today, and the
> meaning I've been wanting to give them is useful and logical.

It's useful to you, personally.  It wouldn't be useful to me.

> I've been using the arrow key setup for years locally and it works very
> well. It really does make window management much less annoying, and
> it's not like we're going to use the arrow keys for anything else under
> C-x 4.

You've been using C-x 4 <arrow key> for your purposes, and other users
will be using them for their purposes, likely to be different from yours.

> As for windmove being used by users --- well, wouldn't it be nice if we
> had metrics like other modern software projects?

Xah Lee developed just such a program, inviting users to submit their
results to him for aggregation.  This was around 10 years ago.  What came
out was largely that different users use Emacs very differently - an
everyday command for one user was totally unused by another.

> But that aside, even if windmove is sparsely used today, might that be
> because it's inconvenient to use without bindings?

It might, but it's unlikely.  Even C-x 4 <up> would be inconvenient for
me.  I have other-window bound to <f12> and rarely have more than three
or four windows in a frame.  I'd hit <f12> two or three times rather
going through the rigmarole of C-x 4 <up>.

As I said, C-x 4 <arrow keys> are convenient to you for windmove
commands.  They'll be convenient to other users for other commands in
just the same way.  You're proposing imposing your setup on everybody.
I'm against this.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Stefan Kangas]

Alan Mackenzie <acm@muc.de> writes:

> As I said, C-x 4 <arrow keys> are convenient to you for windmove
> commands.  They'll be convenient to other users for other commands in
> just the same way.  You're proposing imposing your setup on everybody.
> I'm against this.

I think "imposing" is overstating the case, given that anyone can
easily unbind or rebind keybindings they don't like.

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Stefan.

On Sun, Jun 23, 2024 at 05:30:32 -0700, Stefan Kangas wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > As I said, C-x 4 <arrow keys> are convenient to you for windmove
> > commands.  They'll be convenient to other users for other commands in
> > just the same way.  You're proposing imposing your setup on everybody.
> > I'm against this.

> I think "imposing" is overstating the case, given that anyone can
> easily unbind or rebind keybindings they don't like.

Maybe.  The post I was responding to didn't consist entirely of nuanced
reasoned argument either.

I also think "... can easily unbind or rebind keybindings ..." is also
an exaggeration.  It can be done, yes, by somebody who knows how, but
finding where to unbind them and how is more than just a few minutes
work for the typical user.

I speak from experience here.  org mode binds some arrow key
combinations.  Two of these, C-S-<up> and C-S-<down> which do some minor
thing in org mode are bindings I use to scroll the current window
down/up 6 lines.  So, when somebody changed NEWS from outline mode to
org mode some while ago, my finger memory stopped working.  I never got
around to disabling these bindings in org mode - it was just too much
work.

If we bind C-x 4 <arrow keys> to windmove commands, we will be imposing
just that inconvenience on people who already use the bindings for other
commands.  I don't think it's justified in this particular case.  Those
who need these bindings can bind them themselves, just as Daniel has
done.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 23, 2024 9:29:21 AM EDT, Alan Mackenzie <acm@muc.de> wrote:
>Hello, Stefan.
>
>On Sun, Jun 23, 2024 at 05:30:32 -0700, Stefan Kangas wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > As I said, C-x 4 <arrow keys> are convenient to you for windmove
>> > commands.  They'll be convenient to other users for other commands in
>> > just the same way.  You're proposing imposing your setup on everybody.
>> > I'm against this.
>
>> I think "imposing" is overstating the case, given that anyone can
>> easily unbind or rebind keybindings they don't like.
>
>Maybe.  The post I was responding to didn't consist entirely of nuanced
>reasoned argument either.
>
>I also think "... can easily unbind or rebind keybindings ..." is also
>an exaggeration.  It can be done, yes, by somebody who knows how, but
>finding where to unbind them and how is more than just a few minutes
>work for the typical user.
>
>I speak from experience here.  org mode binds some arrow key
>combinations.  Two of these, C-S-<up> and C-S-<down> which do some minor
>thing in org mode are bindings I use to scroll the current window
>down/up 6 lines.  So, when somebody changed NEWS from outline mode to
>org mode some while ago, my finger memory stopped working.  I never got
>around to disabling these bindings in org mode - it was just too much
>work.

That's getting into spacebar heating territory. It's two lines of code. We shouldn't inconvenience every user everywhere just to save some theoretical person time rebinding keys. Also, because we're talking about the global keymap, not a minor mode one, users don't have to do anything special to override our keybindings with theirs --- define-key will Just Work. Again, you're presenting a general purpose argument against the whole concept of defaults. 

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> Date: Sun, 23 Jun 2024 13:29:21 +0000
> Cc: Daniel Colascione <dancol@dancol.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> I speak from experience here.  org mode binds some arrow key
> combinations.  Two of these, C-S-<up> and C-S-<down> which do some minor
> thing in org mode are bindings I use to scroll the current window
> down/up 6 lines.  So, when somebody changed NEWS from outline mode to
> org mode some while ago

NEWS is not visited using Org mode, it uses a special News mode, which
is a minor variation of Outline mode.

Re: Proposal: new default bindings for winner and windmove

[chad]

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

On Sun, Jun 23, 2024 at 9:46 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 23 Jun 2024 13:29:21 +0000
> > Cc: Daniel Colascione <dancol@dancol.org>,
> >  Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> >
> > I speak from experience here.  org mode binds some arrow key
> > combinations.  Two of these, C-S-<up> and C-S-<down> which do some minor
> > thing in org mode are bindings I use to scroll the current window
> > down/up 6 lines.  So, when somebody changed NEWS from outline mode to
> > org mode some while ago
>
> NEWS is not visited using Org mode, it uses a special News mode, which
> is a minor variation of Outline mode.
>

When I run emacs -Q, there is no binding for C-S-Up in Emacs News. That
said:

(use-package org :bind (:map org-mode-map
>                         ("C-S-<up>" . nil)

                        ("C-S-<down>" . nil)))


Hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 1986 bytes --]

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> > C-x 4 <arrow keys> are convenient to you for windmove
> > commands.  They'll be convenient to other users for
> > other commands in just the same way.  You're proposing
> > imposing your setup on everybody.  I'm against this.
> 
> I think "imposing" is overstating the case, given that anyone can
> easily unbind or rebind keybindings they don't like.

Defining new default bindings is an imposition
on Emacs itself, and all Emacs users, in spite
of the fact that users can override them (they
can override ANY bindings).

True, a default doesn't impose the behavior
absolutely.  But it does impose it as, exactly,
a default.  IOW, there's a real difference
between (1) a key not having default behavior
(not being bound) and (2) a key doing something
by default.

Let's not argue over meanings of "impose".  The
only question is whether to "waste" yet another
key by giving it a default binding.

"Waste"?  Yes, that may be strong.  But if we
give such keys _these_ default bindings then
we can't easily, and likely won't, give them
different default bindings at some point.

The question should be, "Is it important
enough to expend these (rare, precious)
undefined keys on these particular proposed
bindings, which will preclude (practically)
giving them other, better default bindings
at some point in the future.

In a nutshell, ask ourselves whether we
_have_ to define such default bindings now.
Is it really important to do so (now)?

IMHO, the right approach is to add the
commands and _not_ bind them.  Then after a
long period of time, see how users are
_actually_ binding them (if at all), and
decide THEN whether Emacs should spend some
default bindings for them.

That has the effect of letting _users_
decide, in practice.

That's generally the approach Emacs has
taken in the past.  But yes, it's true that
in some cases new commands have immediately
been given default bindings.

(And unfortunately, IMO, such exceptions
-- gratuitous immediate grants of default
bindings -- have been happening a bit more
frequently recently.)

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 23, 2024 8:05:22 AM EDT, Alan Mackenzie <acm@muc.de> wrote:
>Hello, Daniel.
>
>On Sun, Jun 23, 2024 at 07:14:25 -0400, Daniel Colascione wrote:
>
>
>> On June 23, 2024 6:05:13 AM EDT, Alan Mackenzie <acm@muc.de> wrote:
>> >Hello, Stefan and Stefan.
>
>> >On Fri, Jun 21, 2024 at 15:39:09 -0500, Stefan Kangas wrote:
>> >> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> >> > A few years ago, Daniel suggested:
>> >> >> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
>> >> >> for people automatically, enabled by default.
>
>> >> > AFAICT we still don't actually provide any keybindings for the windmove
>> >> > commands by default.  Did I miss a controversy about that, or did it
>> >> > just fall through the cracks?
>
>> >> FWIW, I don't remember any controversy either, so my guess is that it
>> >> just fell through the cracks.
>
>> >I would be against using C-x 4 <arrow keys> or C-x 5 <arrow-keys> for
>> >windmove (or anything else) by default.  Key sequences with arrow keys
>> >are too few, and too precious, to use for anything not critically
>> >important.
>
>> >windmove is not critically important.  Either it isn't used at all by a
>> >user (likely most users), or it is used all the time (by a small number
>> >of users).  In the latter case, the user will already have bound the
>> >commands to key sequences, since they are not useful called from M-x.
>
>> >It wasn't so long ago that we were removing default key bindings so as
>> >to free them up for other uses.  I don't think there's any reason to
>> >reverse that policy for windmove.  It just isn't important enough.
>
>> >There will be users who've bound these key bindings for their own uses.
>> >Let's not mess these users around.
>
>> The arrow keys don't have any meaning after C-x 4 today, and the
>> meaning I've been wanting to give them is useful and logical.
>
>It's useful to you, personally.  It wouldn't be useful to me.
>
>> I've been using the arrow key setup for years locally and it works very
>> well. It really does make window management much less annoying, and
>> it's not like we're going to use the arrow keys for anything else under
>> C-x 4.
>
>You've been using C-x 4 <arrow key> for your purposes, and other users
>will be using them for their purposes, likely to be different from yours.

So? Nobody is preventing those users doing what they want with their key bindings.  You're making a general purpose argument against having default key bindings at all. Why don't we just ship Emacs with an empty global keymap so we're not imposing on anyone?


>
>> As for windmove being used by users --- well, wouldn't it be nice if we
>> had metrics like other modern software projects?
>
>Xah Lee developed just such a program, inviting users to submit their
>results to him for aggregation.  This was around 10 years ago.  What came
>out was largely that different users use Emacs very differently - an
>everyday command for one user was totally unused by another.

Metrics with nontrivial opt-in suffer from selection bias. The sort of person who goes out of his way to enable telemetry is the sort of person who's going to do more customization than the average user.


>
>> But that aside, even if windmove is sparsely used today, might that be
>> because it's inconvenient to use without bindings?
>
>It might, but it's unlikely.  Even C-x 4 <up> would be inconvenient for
>me.  I have other-window bound to <f12> and rarely have more than three
>or four windows in a frame.  I'd hit <f12> two or three times rather
>going through the rigmarole of C-x 4 <up>.

So? How does providing default windmove bindings make your life worse?


>As I said, C-x 4 <arrow keys> are convenient to you for windmove
>commands.  They'll be convenient to other users for other commands in
>just the same way.  You're proposing imposing your setup on everybody.
>I'm against this.

They're not convenient for anyone if left unbound. 

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Daniel Colascione <dancol@dancol.org> writes:

> So? Nobody is preventing those users doing what they want with their
> key bindings.  You're making a general purpose argument against having
> default key bindings at all. Why don't we just ship Emacs with an
> empty global keymap so we're not imposing on anyone?

Replace "having" with "introducing" and you should find that this line
of argument is generally sound.  After all these years, all the commands
that justify being bound by default have already received bindings in
the default keymaps, and plenty of commands that are well in excess of
this criterion.

> Metrics with nontrivial opt-in suffer from selection bias. The sort of
> person who goes out of his way to enable telemetry is the sort of
> person who's going to do more customization than the average user.

Yes.  That does not render mandatory collection of metrics any the less
morally objectionable in a computer program, nor imposing arbitrary
changes on users any more reasonable.

> So? How does providing default windmove bindings make your life worse?

I have bound C-x 4 <down> to ffap-other-window, C-x 4 i to
ibuffer-other-window, and the remaining arrow keys to other commands
that fall into the same -other-window scheme.  I trust there is a
multitude of users besides Alan and myself with their own purposes for
these keys.

> They're not convenient for anyone if left unbound. 

Scarce are the keys that are not bound by default, and therefore may be
customized by users without risking departures in their Emacs sessions
from the expectations of users trained and pastured on uncustomized
sessions.  This is just one, and by far not the most compelling, of many
objections to introducing new default keybindings, but one of which a
recent example comes to mind: C-x x u has for many years been bound in
my sessions to a command that deletes a buffer's undo list, usually in
the interests of security.  The consequences of a stranger's
unsuspectingly typing the same to invoke rename-uniquely might easily
have been catastrophic.
 

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 23, 2024 9:40:06 AM EDT, Po Lu <luangruo@yahoo.com> wrote:
>Daniel Colascione <dancol@dancol.org> writes:
>
>> So? Nobody is preventing those users doing what they want with their
>> key bindings.  You're making a general purpose argument against having
>> default key bindings at all. Why don't we just ship Emacs with an
>> empty global keymap so we're not imposing on anyone?
>
>Replace "having" with "introducing" and you should find that this line
>of argument is generally sound.  After all these years, all the commands
>that justify being bound by default have already received bindings in
>the default keymaps, and plenty of commands that are well in excess of
>this criterion.
>
>> Metrics with nontrivial opt-in suffer from selection bias. The sort of
>> person who goes out of his way to enable telemetry is the sort of
>> person who's going to do more customization than the average user.
>
>Yes.  That does not render mandatory collection of metrics any the less
>morally objectionable in a computer program, nor imposing arbitrary
>changes on users any more reasonable.
>
>> So? How does providing default windmove bindings make your life worse?
>
>I have bound C-x 4 <down> to ffap-other-window, C-x 4 i to
>ibuffer-other-window, and the remaining arrow keys to other commands
>that fall into the same -other-window scheme.  I trust there is a
>multitude of users besides Alan and myself with their own purposes for
>these keys.

I don't trust that many such users exist, and even if they did, providing default keybindings for these keys will not somehow override the keybindings you install yourself.


>
>> They're not convenient for anyone if left unbound. 
>
>Scarce are the keys that are not bound by default, and therefore may be
>customized by users without risking departures in their Emacs sessions
>from the expectations of users trained and pastured on uncustomized
>sessions.  This is just one, and by far not the most compelling, of many
>objections to introducing new default keybindings, but one of which a
>recent example comes to mind: C-x x u has for many years been bound in
>my sessions to a command that deletes a buffer's undo list, usually in
>the interests of security.  The consequences of a stranger's
>unsuspectingly typing the same to invoke rename-uniquely might easily
>have been catastrophic.
> 


This attitude is why Doom Emacs exists. A live software project is one that changes. A dead one prioritizes stasis over user experience.

Nothing we're talking about here will disturb your custom keybindings. Your experience will work just as it did before. The only difference is that users who don't have custom bindings for the arrow keys under C-x 4 will get windmove functionality if they don't customize the bindings. 

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Daniel Colascione <dancol@dancol.org> writes:

> I don't trust that many such users exist, and even if they did,
> providing default keybindings for these keys will not somehow override
> the keybindings you install yourself.

Sure.  And more users stand to benefit from Windmove commands if they
are bound to C-x 4, than if they were required to bind such commands
themselves, commands defined by a package that is already of marginal
interest?  What extraordinary logic!

> This attitude is why Doom Emacs exists. A live software project is one
> that changes. A dead one prioritizes stasis over user experience.

Since Doom Emacs exists and is Free Software, why are users not at
liberty to install it and bid farewell to reaction and "stasis" in Emacs
development?  And why is it a matter for our consideration whether we
fail or succeed in competing with them?  Any mention of "competition"
with an Emacs package is already a contradiction in terms.

> Nothing we're talking about here will disturb your custom
> keybindings. Your experience will work just as it did before. The only
> difference is that users who don't have custom bindings for the arrow
> keys under C-x 4 will get windmove functionality if they don't
> customize the bindings.

Spoken like a true intellectual, in the face of a real-life example to
the contrary.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Alan Mackenzie <acm@muc.de>,  Stefan Kangas <stefankangas@gmail.com>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Sun, 23 Jun 2024 22:15:59 +0800
> 
> Daniel Colascione <dancol@dancol.org> writes:
> 
> > I don't trust that many such users exist, and even if they did,
> > providing default keybindings for these keys will not somehow override
> > the keybindings you install yourself.
> 
> Sure.  And more users stand to benefit from Windmove commands if they
> are bound to C-x 4, than if they were required to bind such commands
> themselves, commands defined by a package that is already of marginal
> interest?  What extraordinary logic!
> 
> > This attitude is why Doom Emacs exists. A live software project is one
> > that changes. A dead one prioritizes stasis over user experience.
> 
> Since Doom Emacs exists and is Free Software, why are users not at
> liberty to install it and bid farewell to reaction and "stasis" in Emacs
> development?  And why is it a matter for our consideration whether we
> fail or succeed in competing with them?  Any mention of "competition"
> with an Emacs package is already a contradiction in terms.
> 
> > Nothing we're talking about here will disturb your custom
> > keybindings. Your experience will work just as it did before. The only
> > difference is that users who don't have custom bindings for the arrow
> > keys under C-x 4 will get windmove functionality if they don't
> > customize the bindings.
> 
> Spoken like a true intellectual, in the face of a real-life example to
> the contrary.

This dispute begins to spill into the not-so-nice area, so I think it
is time for those who already made their opinions abundantly clear to
stop, and let people who have not yet spoken do so.

It is clear that Daniel thought years ago we should have key bindings
for windmove, and still thinks so, and Stefan Monnier agrees with him.
It is also clear that Alan and Po Lu think we shouldn't.  Now let's
hear from others, and please leave it to the Emacs maintainers to
decide what to do with this after we've heard enough opinions.

Re: Proposal: new default bindings for winner and windmove

[Gregor Zattler]

Hi Eli, emacs developers,
* Eli Zaretskii <eliz@gnu.org> [2024-06-23; 17:22 +03]:
> Now let's
> hear from others, and please leave it to the Emacs maintainers to
> decide what to do with this after we've heard enough opinions.

On todays big displays I often have more
than two windows in my only emacs frame.
Other solutions like window-numbers did
not stick with me.  I use the
windmove-{up,down,left,right} commands
all the time.

Since I use more than two windows and at
the same time I'm not able to control
the placements of windows, I value
winner-mode very much.  But because of
the more involved key binding I use it
not as often as would actually be helpful.

I bound the windmove movements to
H-<arrow-keys>.  Since I bound H to the
Caps Lock key this is convenient for me.

I bound winner-{undo,redo} to
C-H-{left,right} for symmetry but forget
that key binding again and again.

Regards, Gregor

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

Gregor Zattler <telegraph@gmx.net> writes:

> Hi Eli, emacs developers,
> * Eli Zaretskii <eliz@gnu.org> [2024-06-23; 17:22 +03]:
>> Now let's
>> hear from others, and please leave it to the Emacs maintainers to
>> decide what to do with this after we've heard enough opinions.
>
> On todays big displays I often have more
> than two windows in my only emacs frame.
> Other solutions like window-numbers did
> not stick with me.  I use the
> windmove-{up,down,left,right} commands
> all the time.
>
> Since I use more than two windows and at
> the same time I'm not able to control
> the placements of windows, I value
> winner-mode very much.  But because of
> the more involved key binding I use it
> not as often as would actually be helpful.
>
> I bound the windmove movements to
> H-<arrow-keys>.  Since I bound H to the
> Caps Lock key this is convenient for me.
>
> I bound winner-{undo,redo} to
> C-H-{left,right} for symmetry but forget
> that key binding again and again.

That's why I bind C-x 4 / to winner-undo.  It creates a nice symmetry
with regular undo.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Gregor Zattler <telegraph@gmx.net>
> Cc: dancol@dancol.org, acm@muc.de, stefankangas@gmail.com,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Date: Mon, 24 Jun 2024 09:41:19 +0200
> 
> I bound the windmove movements to
> H-<arrow-keys>.  Since I bound H to the
> Caps Lock key this is convenient for me.

Thanks.  Do you also turn on windmove-mode?

Re: Proposal: new default bindings for winner and windmove

[Gregor Zattler]

Hi Eli,
* Eli Zaretskii <eliz@gnu.org> [2024-06-24; 15:41 +03]:
>> From: Gregor Zattler <telegraph@gmx.net>
>> Cc: dancol@dancol.org, acm@muc.de, stefankangas@gmail.com,
>>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> Date: Mon, 24 Jun 2024 09:41:19 +0200
>>
>> I bound the windmove movements to
>> H-<arrow-keys>.  Since I bound H to the
>> Caps Lock key this is convenient for me.
>
> Thanks.  Do you also turn on windmove-mode?

yes.

I'm stonished: Wouldn't it not work
without turning on windmove-mode?

Regards, Gregor

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Gregor Zattler <telegraph@gmx.net>
> Cc: luangruo@yahoo.com, dancol@dancol.org, acm@muc.de,
>  stefankangas@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Date: Mon, 24 Jun 2024 17:09:44 +0200
> 
> Hi Eli,
> * Eli Zaretskii <eliz@gnu.org> [2024-06-24; 15:41 +03]:
> >> From: Gregor Zattler <telegraph@gmx.net>
> >> Cc: dancol@dancol.org, acm@muc.de, stefankangas@gmail.com,
> >>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> >> Date: Mon, 24 Jun 2024 09:41:19 +0200
> >>
> >> I bound the windmove movements to
> >> H-<arrow-keys>.  Since I bound H to the
> >> Caps Lock key this is convenient for me.
> >
> > Thanks.  Do you also turn on windmove-mode?
> 
> yes.
> 
> I'm stonished: Wouldn't it not work
> without turning on windmove-mode?

I just wanted to be sure, sorry for astonishing you.

Re: Proposal: new default bindings for winner and windmove

[Joel Reicher]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gregor Zattler <telegraph@gmx.net>
>> Cc: luangruo@yahoo.com, dancol@dancol.org, acm@muc.de, 
>> stefankangas@gmail.com, monnier@iro.umontreal.ca, 
>> emacs-devel@gnu.org
>> Date: Mon, 24 Jun 2024 17:09:44 +0200
>>
>> Hi Eli,
>> * Eli Zaretskii <eliz@gnu.org> [2024-06-24; 15:41 +03]:
>> >> From: Gregor Zattler <telegraph@gmx.net>
>> >> Cc: dancol@dancol.org, acm@muc.de, stefankangas@gmail.com, 
>> >> monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> >> Date: Mon, 24 Jun 2024 09:41:19 +0200
>> >>
>> >> I bound the windmove movements to H-<arrow-keys>.  Since I 
>> >> bound H to the Caps Lock key this is convenient for me.
>> >
>> > Thanks.  Do you also turn on windmove-mode?
>>
>> yes.
>>
>> I'm stonished: Wouldn't it not work without turning on 
>> windmove-mode?
>
> I just wanted to be sure, sorry for astonishing you.
 
Unless I'm confused, windmove-mode is on by default, but not 
loaded, so it can give the impression of being off by default.

Regards,

        - Joel

Re: Proposal: new default bindings for winner and windmove

[Petteri Hintsanen]

Eli Zaretskii <eliz@gnu.org> writes:

> Now let's hear from others, and please leave it to the Emacs
> maintainers to decide what to do with this after we've heard enough
> opinions.

I haven't really followed the discussion closely so I'm not sure what
you want to hear, but none the less:

I use windmove all day and all night with its default keybindings.
I also use winner-mode with its default keybindings.
As for configuration, I have just

  (windmove-default-keybindings)
  (winner-mode 1)

in my init.el.  They have been there for ages.  I am happy with the
default bindings.

Thanks,
Petteri

Re: Proposal: new default bindings for winner and windmove

[Jeremy Bryant]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Alan Mackenzie <acm@muc.de>,  Stefan Kangas <stefankangas@gmail.com>,
>>  Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
>> Date: Sun, 23 Jun 2024 22:15:59 +0800
>> 
>> Daniel Colascione <dancol@dancol.org> writes:
>> 
>> > I don't trust that many such users exist, and even if they did,
>> > providing default keybindings for these keys will not somehow override
>> > the keybindings you install yourself.
>> 
>> Sure.  And more users stand to benefit from Windmove commands if they
>> are bound to C-x 4, than if they were required to bind such commands
>> themselves, commands defined by a package that is already of marginal
>> interest?  What extraordinary logic!
>> 
>> > This attitude is why Doom Emacs exists. A live software project is one
>> > that changes. A dead one prioritizes stasis over user experience.
>> 
>> Since Doom Emacs exists and is Free Software, why are users not at
>> liberty to install it and bid farewell to reaction and "stasis" in Emacs
>> development?  And why is it a matter for our consideration whether we
>> fail or succeed in competing with them?  Any mention of "competition"
>> with an Emacs package is already a contradiction in terms.
>> 
>> > Nothing we're talking about here will disturb your custom
>> > keybindings. Your experience will work just as it did before. The only
>> > difference is that users who don't have custom bindings for the arrow
>> > keys under C-x 4 will get windmove functionality if they don't
>> > customize the bindings.
>> 
>> Spoken like a true intellectual, in the face of a real-life example to
>> the contrary.
>
> This dispute begins to spill into the not-so-nice area, so I think it
> is time for those who already made their opinions abundantly clear to
> stop, and let people who have not yet spoken do so.
>
> It is clear that Daniel thought years ago we should have key bindings
> for windmove, and still thinks so, and Stefan Monnier agrees with him.
> It is also clear that Alan and Po Lu think we shouldn't.  Now let's
> hear from others, and please leave it to the Emacs maintainers to
> decide what to do with this after we've heard enough opinions.

Here for another opinion on the narrow topic of the proposed bindings.
I originally set up the C-x 4 bindings on Daniel's suggestion in the
original thread (~2021):

1.
I also find that C-x 4 is indeed logical, which makes it easier to remember

2.
C-x 4 .. works on the terminal/console.  This is important for
preserving functionality of Emacs.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Jeremy Bryant <jb@jeremybryant.net>
> Cc: Po Lu <luangruo@yahoo.com>,  dancol@dancol.org,  acm@muc.de,
>   stefankangas@gmail.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Tue, 25 Jun 2024 22:26:47 +0100
> 
> 1.
> I also find that C-x 4 is indeed logical, which makes it easier to remember
> 
> 2.
> C-x 4 .. works on the terminal/console.  This is important for
> preserving functionality of Emacs.

I still hope that someone will tell what is exactly the request here,
given that windmove-mode is on by default and its commands are
autoloaded.

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 26, 2024 7:23:38 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Jeremy Bryant <jb@jeremybryant.net>
>> Cc: Po Lu <luangruo@yahoo.com>,  dancol@dancol.org,  acm@muc.de,
>>   stefankangas@gmail.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
>> Date: Tue, 25 Jun 2024 22:26:47 +0100
>> 
>> 1.
>> I also find that C-x 4 is indeed logical, which makes it easier to remember
>> 
>> 2.
>> C-x 4 .. works on the terminal/console.  This is important for
>> preserving functionality of Emacs.
>
>I still hope that someone will tell what is exactly the request here,
>given that windmove-mode is on by default and its commands are
>autoloaded.

To be clear, my proposal is to bind C-x 4 <arrow> in the default global keymap to the corresponding directional windmove commands and to bind the shifted versions of these keys to the state swapping versions of these movement commands. IOW, in emacs -Q, C-x 4 LEFT should move left.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> Date: Wed, 26 Jun 2024 07:44:19 -0400
> From: Daniel Colascione <dancol@dancol.org>
> CC: luangruo@yahoo.com, acm@muc.de, stefankangas@gmail.com,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> 
> 
> On June 26, 2024 7:23:38 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
> >I still hope that someone will tell what is exactly the request here,
> >given that windmove-mode is on by default and its commands are
> >autoloaded.
> 
> To be clear, my proposal is to bind C-x 4 <arrow> in the default global keymap to the corresponding directional windmove commands and to bind the shifted versions of these keys to the state swapping versions of these movement commands. IOW, in emacs -Q, C-x 4 LEFT should move left.

Thanks, but how should we do that without breaking
windmove-default-keybindings for those users who use it?

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 26, 2024 9:19:58 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 26 Jun 2024 07:44:19 -0400
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: luangruo@yahoo.com, acm@muc.de, stefankangas@gmail.com,
>>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> 
>> 
>> 
>> On June 26, 2024 7:23:38 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> >I still hope that someone will tell what is exactly the request here,
>> >given that windmove-mode is on by default and its commands are
>> >autoloaded.
>> 
>> To be clear, my proposal is to bind C-x 4 <arrow> in the default global keymap to the corresponding directional windmove commands and to bind the shifted versions of these keys to the state swapping versions of these movement commands. IOW, in emacs -Q, C-x 4 LEFT should move left.
>
>Thanks, but how should we do that without breaking
>windmove-default-keybindings for those users who use it?

... by not touching windmove-default-keybindings, except perhaps to mark it obsolete? Adding bindings to the default keymap does not interfere in any way with what windmove-default-keybindings does.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> Date: Wed, 26 Jun 2024 09:57:30 -0400
> From: Daniel Colascione <dancol@dancol.org>
> CC: jb@jeremybryant.net, luangruo@yahoo.com, acm@muc.de, stefankangas@gmail.com,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> >> To be clear, my proposal is to bind C-x 4 <arrow> in the default global keymap to the corresponding directional windmove commands and to bind the shifted versions of these keys to the state swapping versions of these movement commands. IOW, in emacs -Q, C-x 4 LEFT should move left.
> >
> >Thanks, but how should we do that without breaking
> >windmove-default-keybindings for those users who use it?
> 
> ... by not touching windmove-default-keybindings, except perhaps to mark it obsolete? Adding bindings to the default keymap does not interfere in any way with what windmove-default-keybindings does.

So people who use windmove-default-keybindings will now have these
commands bound to more than one key sequence?  I hoped we could come
up with a more elegant solution.

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 26, 2024 11:38:32 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 26 Jun 2024 09:57:30 -0400
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: jb@jeremybryant.net, luangruo@yahoo.com, acm@muc.de, stefankangas@gmail.com,
>>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> 
>> >> To be clear, my proposal is to bind C-x 4 <arrow> in the default global keymap to the corresponding directional windmove commands and to bind the shifted versions of these keys to the state swapping versions of these movement commands. IOW, in emacs -Q, C-x 4 LEFT should move left.
>> >
>> >Thanks, but how should we do that without breaking
>> >windmove-default-keybindings for those users who use it?
>> 
>> ... by not touching windmove-default-keybindings, except perhaps to mark it obsolete? Adding bindings to the default keymap does not interfere in any way with what windmove-default-keybindings does.
>
>So people who use windmove-default-keybindings will now have these
>commands bound to more than one key sequence?  

Yeah. This situation strikes me as only slightly ugly though, and I don't see another way to reconcile the compatibility constraints with adding new keybindings. Would we remove the global C-x 4 bindings when someone called windmove-default-keybindings? That doesn't strike me as the surprise-minimizing option.

I hoped we could come
>up with a more elegant solution.

Re: Proposal: new default bindings for winner and windmove

[Hovav Shacham]

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

On Wed, Jun 26, 2024, at 8:57 AM, Daniel Colascione wrote:

> >Thanks, but how should we do that without breaking
> >windmove-default-keybindings for those users who use it?
> 
> ... by not touching windmove-default-keybindings, except perhaps to mark it obsolete? Adding bindings to the default keymap does not interfere in any way with what windmove-default-keybindings does.

Y'all,

I'm the original author of windmove.el; apologies for weighing in late in the discussion.

The windmove functionality has been bound to shift-<arrow> or alt-<arrow> since the late '80s (in the BRIEF editor), and since the late '90s in Emacs, through `windmove-default-keybindings'.  Would deprecating these bindings and assigning entirely new ones be a net win?

In BRIEF, <f1> followed by <arrow> was another binding for selecting a window by direction, and <f2>, <f3>, and <f4> followed by <arrow> would resize, create, or delete a window by direction, respectively.  If we think that windmove functionality needs to be in the default keymap, perhaps these bindings could be replicated?  Then `windmove-default-keybindings' could become `windmove-enable-quick-keybindings' or similar.

(For reference, the BRIEF bindings are described on pages 84--89 of the BRIEF 3.1 user manual, available at http://www.bitsavers.org/pdf/borland/BRIEF_for_DOS_and_OS2_Version_3.1_Users_Guide_1992.pdf)

-hs.

[-- Attachment #2: Type: text/html, Size: 1996 bytes --]

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

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

One opinion -

I don't much care what bindings you offer by default for it, provided you don't just enable them by default when the library is simply loaded.

Instead, put them behind some clear, explicit user choice.

A good way to do that is to have a user option that puts them into effect. Another good way is to have users put them into effect by turning on a minor mode, i.e., give them minor-mode bindings.

From: Hovav ShachamSent: Friday, June 28, 2024 12:47 PM
On Wed, Jun 26, 2024, at 8:57 AM, Daniel Colascione wrote:

I'm the original author of windmove.el; apologies for weighing in late in the discussion.

The windmove functionality has been bound to shift-<arrow> or alt-<arrow> since the late '80s (in the BRIEF editor), and since the late '90s in Emacs, through `windmove-default-keybindings'.  Would deprecating these bindings and assigning entirely new ones be a net win?

In BRIEF, <f1> followed by <arrow> was another binding for selecting a window by direction, and <f2>, <f3>, and <f4> followed by <arrow> would resize, create, or delete a window by direction, respectively.  If we think that windmove functionality needs to be in the default keymap, perhaps these bindings could be replicated?  Then `windmove-default-keybindings' could become `windmove-enable-quick-keybindings' or similar.

(For reference, the BRIEF bindings are described on pages 84--89 of the BRIEF 3.1 user manual, available at http://www.bitsavers.org/pdf/borland/BRIEF_for_DOS_and_OS2_Version_3.1_Users_Guide_1992.pdf<https://urldefense.com/v3/__http:/www.bitsavers.org/pdf/borland/BRIEF_for_DOS_and_OS2_Version_3.1_Users_Guide_1992.pdf__;!!ACWV5N9M2RV99hQ!KpQ_KQ-XiGZLe0-jeJYEQNPoi1jRcS3qYqXpmQGffJpaD5f84RlZiCsYSnc4R2CxwVZU2WQr3tLgWA$>)

-hs.

[-- Attachment #2: Type: text/html, Size: 5851 bytes --]

Re: [External] : Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "jb@jeremybryant.net" <jb@jeremybryant.net>,
>         "luangruo@yahoo.com"
> 	<luangruo@yahoo.com>, "acm@muc.de" <acm@muc.de>,
>         "stefankangas@gmail.com"
> 	<stefankangas@gmail.com>,
>         "monnier@iro.umontreal.ca"
> 	<monnier@iro.umontreal.ca>,
>         "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Fri, 28 Jun 2024 20:45:22 +0000
> 
> One opinion -
> 
> I don't much care what bindings you offer by default for it, provided you don't just enable them by default when
> the library is simply loaded.
> 
> Instead, put them behind some clear, explicit user choice.

This opinion of yours was already expressed several times in this
thread, and was noted.  No need to reiterate it anymore.

Re: Proposal: new default bindings for winner and windmove

[Stefan Kangas]

"Hovav Shacham" <hovav@hovav.net> writes:

> The windmove functionality has been bound to shift-<arrow> or
> alt-<arrow> since the late '80s (in the BRIEF editor), and since the
> late '90s in Emacs, through `windmove-default-keybindings'.  Would
> deprecating these bindings and assigning entirely new ones be a net
> win?

I don't think the original proposal included deprecating these
keybindings.  Even if it did, I don't think that's a good idea, since
they have been there for a long time, and are only installed optionally.

We can leave `windmove-default-keybindings` the way it is now.

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Daniel.

On Wed, Jun 26, 2024 at 07:44:19 -0400, Daniel Colascione wrote:


> On June 26, 2024 7:23:38 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Jeremy Bryant <jb@jeremybryant.net>
> >> Cc: Po Lu <luangruo@yahoo.com>,  dancol@dancol.org,  acm@muc.de,
> >>   stefankangas@gmail.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> >> Date: Tue, 25 Jun 2024 22:26:47 +0100

> >> 1.
> >> I also find that C-x 4 is indeed logical, which makes it easier to remember

> >> 2.
> >> C-x 4 .. works on the terminal/console.  This is important for
> >> preserving functionality of Emacs.

> >I still hope that someone will tell what is exactly the request here,
> >given that windmove-mode is on by default and its commands are
> >autoloaded.

> To be clear, my proposal is to bind C-x 4 <arrow> in the default
> global keymap to the corresponding directional windmove commands and
> to bind the shifted versions of these keys to the state swapping
> versions of these movement commands. IOW, in emacs -Q, C-x 4 LEFT
> should move left.

That doesn't clear up all that much.  The answers to "why?" are missing.
I don't think there need to be such bindings in the default keymap.

As Eli said, windmove is autoloaded, including its command
windmove-default-keybindings.  By default, this binds S-<up> etc., which
strike me as better bindings than C-x 4 <up> etc. for anybody not using
these bindings for anything else.  C-x 4 <up> might be convenient for
those on tty's whose keyboard layout lacks <modifier(s)>-<up>, but
hardly on a GUI Emacs.

Possibly, windmove-default-keybindings could be enhanced to allow a
prefix key binding to be given as an alternative to a set of modifiers.
Possibly.

So, currently, windmove is easily available to anybody that wants it,
and doesn't "waste" the key bindings of those who don't.  Why is the
current state unsatisfactory, and why do you want to make these new
bindings?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 26, 2024 9:22:10 AM EDT, Alan Mackenzie <acm@muc.de> wrote:
>Hello, Daniel.
>
>On Wed, Jun 26, 2024 at 07:44:19 -0400, Daniel Colascione wrote:
>
>
>> On June 26, 2024 7:23:38 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> From: Jeremy Bryant <jb@jeremybryant.net>
>> >> Cc: Po Lu <luangruo@yahoo.com>,  dancol@dancol.org,  acm@muc.de,
>> >>   stefankangas@gmail.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
>> >> Date: Tue, 25 Jun 2024 22:26:47 +0100
>
>> >> 1.
>> >> I also find that C-x 4 is indeed logical, which makes it easier to remember
>
>> >> 2.
>> >> C-x 4 .. works on the terminal/console.  This is important for
>> >> preserving functionality of Emacs.
>
>> >I still hope that someone will tell what is exactly the request here,
>> >given that windmove-mode is on by default and its commands are
>> >autoloaded.
>
>> To be clear, my proposal is to bind C-x 4 <arrow> in the default
>> global keymap to the corresponding directional windmove commands and
>> to bind the shifted versions of these keys to the state swapping
>> versions of these movement commands. IOW, in emacs -Q, C-x 4 LEFT
>> should move left.
>
>That doesn't clear up all that much.  The answers to "why?" are missing.
>I don't think there need to be such bindings in the default keymap.
>
>As Eli said, windmove is autoloaded, including its command
>windmove-default-keybindings.  By default, this binds S-<up> etc., which
>strike me as better bindings than C-x 4 <up> etc. for anybody not using
>these bindings for anything else.  C-x 4 <up> might be convenient for
>those on tty's whose keyboard layout lacks <modifier(s)>-<up>, but
>hardly on a GUI Emacs.
>
>Possibly, windmove-default-keybindings could be enhanced to allow a
>prefix key binding to be given as an alternative to a set of modifiers.
>Possibly.
>
>So, currently, windmove is easily available to anybody that wants it,
>and doesn't "waste" the key bindings of those who don't.

There is no "waste". We've gone over this at length. People who want to bind these keys can bind them still. Nobody is hurt by default bindings being present, and all the arguments I've seen against these bindings are also arguments against having default bindings at all.

There's no need to augment the binding function with a new parameter. Anyone who can use the new parameter can just bind the keys directly. The point is that out of the box Emacs should be useful and useable, that the lack of default bindings for windmove makes it less so, and that there's little downside to adding these bindings. 

 > Why is the
>current state unsatisfactory, and why do you want to make these new
>bindings?

Because it's useful to navigate windows positionally as well as temporally. Other-window often has unpredictable effects and navigating with windmove DWIM.




>

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Daniel Colascione <dancol@dancol.org> writes:

> There is no "waste". We've gone over this at length. People who want
> to bind these keys can bind them still. Nobody is hurt by default
> bindings being present, and all the arguments I've seen against these
> bindings are also arguments against having default bindings at all.

[...]

> There's no need to augment the binding function with a new
> parameter. Anyone who can use the new parameter can just bind the keys
> directly. The point is that out of the box Emacs should be useful and
> useable, that the lack of default bindings for windmove makes it less
> so, and that there's little downside to adding these bindings.

"I was not convinced by you, and therefore you must all agree with ME."

> Because it's useful to navigate windows positionally as well as
> temporally. Other-window often has unpredictable effects and
> navigating with windmove DWIM.

Most users will for this purpose use the mouse, if there is really such
a number of windows that navigating with other-window is impractical.

I'm disposed to say that this situation seldom appears in practice, or
we should have received proposals to grant windmove default keybindings
much earlier.  And don't let's be given a lecture as to the inherent
incompatibility of the mouse with Emacs's ethos or some such.

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

Po Lu <luangruo@yahoo.com> writes:

> Daniel Colascione <dancol@dancol.org> writes:
>
>> There is no "waste". We've gone over this at length. People who want
>> to bind these keys can bind them still. Nobody is hurt by default
>> bindings being present, and all the arguments I've seen against these
>> bindings are also arguments against having default bindings at all.
>
> [...]
>
>> There's no need to augment the binding function with a new
>> parameter. Anyone who can use the new parameter can just bind the keys
>> directly. The point is that out of the box Emacs should be useful and
>> useable, that the lack of default bindings for windmove makes it less
>> so, and that there's little downside to adding these bindings.
>
> "I was not convinced by you, and therefore you must all agree with ME."
>
>> Because it's useful to navigate windows positionally as well as
>> temporally. Other-window often has unpredictable effects and
>> navigating with windmove DWIM.
>
> Most users will for this purpose use the mouse, if there is really such
> a number of windows that navigating with other-window is impractical.

That Emacs, of all programs, is mouse-centric and therefore needs no
keybindings for certain functions is a curious claim.

> I'm disposed to say that this situation seldom appears in practice, or
> we should have received proposals to grant windmove default keybindings
> much earlier.

Another curious argument is that a problem X isn't actually a problem
because, if it were, it would have been solved already. That's true only
in the limit as time goes to infinity.

>  And don't let's be given a lecture as to the inherent
> incompatibility of the mouse with Emacs's ethos or some such.

What you're doing here is called "poisoning the well" and is another
invalid form of discourse.  Making certain functionality mouse-only is,
in fact, contrary to longstanding tradition.

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Daniel Colascione <dancol@dancol.org> writes:

>> Most users will for this purpose use the mouse, if there is really such
>> a number of windows that navigating with other-window is impractical.
>
> That Emacs, of all programs, is mouse-centric and therefore needs no
> keybindings for certain functions is a curious claim.

Real men don't attack straw men.  Anyone can see the enormous disconnect
between your paraphrasing and the original.

> Another curious argument is that a problem X isn't actually a problem
> because, if it were, it would have been solved already. That's true only
> in the limit as time goes to infinity.

"It would have been MENTIONED already."

> What you're doing here is called "poisoning the well" and is another
> invalid form of discourse.

Before convicting your opponent of the cardinal sin of committing an
_informal_ fallacy, it would serve you well to ensure that the validity
of what he has said is truly dependent on the fallacious statement being
accepted.  That is, that the so-called fallacy is not no more central to
his meaning than any other rhetorical device.  But I understand that it
is immensely tempting to pounce upon "invalid forms of discourse" by way
of immediately asserting victory, just as the thrill of winning is more
enjoyable than earnest persuasion.

> Making certain functionality mouse-only is, in fact, contrary to
> longstanding tradition.

For the lion's share of users unwilling to use the mouse, other-window
is perfectly adequate.  Or we would have heard otherwise long ago.

Whether Alan is a user of Windmove, I don't know, but he does not
believe it to justify default keybindings in the C-x 4 keymap.  I have
never used Windmove, because I am perfectly content with the status quo.
Eli did not so much as understand your proposal at first.  No others
have referred to having installed keybindings agreeing exactly with
yours, whatsoever concurrence they might have expressed, from which it
is easy to conclude that your choices are so universal as preferences
for text editor or tea versus coffee--that is to say, not universal at
all.

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Po.

On Wed, Jun 26, 2024 at 23:15:04 +0800, Po Lu wrote:

[ .... ]

> > Making certain functionality mouse-only is, in fact, contrary to
> > longstanding tradition.

> For the lion's share of users unwilling to use the mouse, other-window
> is perfectly adequate.  Or we would have heard otherwise long ago.

other-window (which I've bound to <f12>) is entirely satisfactory to me,
a user who doesn't like the mouse.

> Whether Alan is a user of Windmove, I don't know, but he does not
> believe it to justify default keybindings in the C-x 4 keymap.

I don't use windmove, no, but I can see its usefulness for some people.

I use <f1>, <f2>, .... to switch to frames F1, F2, ... etc.  I think
that's a tremendously useful facility, more so than windmove, but I'm
not about to be suggesting these bindings should go into the default key
maps.

> I have never used Windmove, because I am perfectly content with the
> status quo.  Eli did not so much as understand your proposal at first.
> No others have referred to having installed keybindings agreeing
> exactly with yours, whatsoever concurrence they might have expressed,
> from which it is easy to conclude that your choices are so universal
> as preferences for text editor or tea versus coffee--that is to say,
> not universal at all.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Colin Baxter]

I will like to advocate for my own superior windmove-default-keybindings of
<super> + arrows left, right, etc. :-)

Best wishes,

Colin Baxter.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Colin Baxter <m43cap@yandex.com>
> Cc: Daniel Colascione <dancol@dancol.org>,  Alan Mackenzie <acm@muc.de>,
>   Eli Zaretskii <eliz@gnu.org>,  Jeremy Bryant <jb@jeremybryant.net>,
>   stefankangas@gmail.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Wed, 26 Jun 2024 16:42:52 +0100
> 
> 
> I will like to advocate for my own superior windmove-default-keybindings of
> <super> + arrows left, right, etc. :-)

That's already supported by windmove-default-keybindings, no?

Re: Proposal: new default bindings for winner and windmove

[Joel Reicher]

Po Lu <luangruo@yahoo.com> writes:

> Daniel Colascione <dancol@dancol.org> writes:
>
>> Because it's useful to navigate windows positionally as well as 
>> temporally. Other-window often has unpredictable effects and 
>> navigating with windmove DWIM.
>
> Most users will for this purpose use the mouse, if there is 
> really such a number of windows that navigating with 
> other-window is impractical.
>
> I'm disposed to say that this situation seldom appears in 
> practice, or we should have received proposals to grant windmove 
> default keybindings much earlier.  And don't let's be given a 
> lecture as to the inherent incompatibility of the mouse with 
> Emacs's ethos or some such.

Please can we err on the side of *choice*.

I for one very much enjoy staying away from the mouse and 
navigating four or more windows with windmove, but I can well 
imagine some others may use the mouse.

I don't think it's necessary to guess at the majority, and I think 
it improves the experience for everyone if we don't.

Thanks and regards,

       - Joel

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Alan Mackenzie <acm@muc.de>,  Eli Zaretskii <eliz@gnu.org>,  Jeremy
>  Bryant <jb@jeremybryant.net>,  stefankangas@gmail.com,
>   monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Wed, 26 Jun 2024 22:13:23 +0800
> 
> Daniel Colascione <dancol@dancol.org> writes:
> 
> > There is no "waste". We've gone over this at length. People who want
> > to bind these keys can bind them still. Nobody is hurt by default
> > bindings being present, and all the arguments I've seen against these
> > bindings are also arguments against having default bindings at all.
> 
> [...]
> 
> > There's no need to augment the binding function with a new
> > parameter. Anyone who can use the new parameter can just bind the keys
> > directly. The point is that out of the box Emacs should be useful and
> > useable, that the lack of default bindings for windmove makes it less
> > so, and that there's little downside to adding these bindings.
> 
> "I was not convinced by you, and therefore you must all agree with ME."
> 
> > Because it's useful to navigate windows positionally as well as
> > temporally. Other-window often has unpredictable effects and
> > navigating with windmove DWIM.
> 
> Most users will for this purpose use the mouse, if there is really such
> a number of windows that navigating with other-window is impractical.
> 
> I'm disposed to say that this situation seldom appears in practice, or
> we should have received proposals to grant windmove default keybindings
> much earlier.  And don't let's be given a lecture as to the inherent
> incompatibility of the mouse with Emacs's ethos or some such.

Didn't I ask not to reiterate the opinions that were already heard,
and heard abundantly?  I heard you the first time (and the second, and
the third, and...), and I understand very well that you are opposed to
this change.  Why keep saying it time and again, when doing so doesn't
add any useful information to the discussion?

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Daniel.

On Wed, Jun 26, 2024 at 09:51:41 -0400, Daniel Colascione wrote:


> On June 26, 2024 9:22:10 AM EDT, Alan Mackenzie <acm@muc.de> wrote:
> >On Wed, Jun 26, 2024 at 07:44:19 -0400, Daniel Colascione wrote:


> >> On June 26, 2024 7:23:38 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
> >> >> From: Jeremy Bryant <jb@jeremybryant.net>
> >> >> Cc: Po Lu <luangruo@yahoo.com>,  dancol@dancol.org,  acm@muc.de,
> >> >>   stefankangas@gmail.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> >> >> Date: Tue, 25 Jun 2024 22:26:47 +0100

> >> >> 1.
> >> >> I also find that C-x 4 is indeed logical, which makes it easier to remember

> >> >> 2.
> >> >> C-x 4 .. works on the terminal/console.  This is important for
> >> >> preserving functionality of Emacs.

> >> >I still hope that someone will tell what is exactly the request here,
> >> >given that windmove-mode is on by default and its commands are
> >> >autoloaded.

> >> To be clear, my proposal is to bind C-x 4 <arrow> in the default
> >> global keymap to the corresponding directional windmove commands and
> >> to bind the shifted versions of these keys to the state swapping
> >> versions of these movement commands. IOW, in emacs -Q, C-x 4 LEFT
> >> should move left.

> >That doesn't clear up all that much.  The answers to "why?" are missing.
> >I don't think there need to be such bindings in the default keymap.

> >As Eli said, windmove is autoloaded, including its command
> >windmove-default-keybindings.  By default, this binds S-<up> etc., which
> >strike me as better bindings than C-x 4 <up> etc. for anybody not using
> >these bindings for anything else.  C-x 4 <up> might be convenient for
> >those on tty's whose keyboard layout lacks <modifier(s)>-<up>, but
> >hardly on a GUI Emacs.

> >Possibly, windmove-default-keybindings could be enhanced to allow a
> >prefix key binding to be given as an alternative to a set of modifiers.
> >Possibly.

> >So, currently, windmove is easily available to anybody that wants it,
> >and doesn't "waste" the key bindings of those who don't.

> There is no "waste". We've gone over this at length. People who want to
> bind these keys can bind them still. Nobody is hurt by default bindings
> being present, and all the arguments I've seen against these bindings
> are also arguments against having default bindings at all.

And round and round we go once more...  Just the puerile strawman again,
about either definitely needing these new default bindings or not needing
any default bindings whatsoever.

What makes you think that unneeded default bindings don't hurt?  I don't
think you've justified that at all in the current thread.

> There's no need to augment the binding function with a new parameter.
> Anyone who can use the new parameter can just bind the keys directly.
> The point is that out of the box Emacs should be useful and useable,
> that the lack of default bindings for windmove makes it less so, and
> that there's little downside to adding these bindings. 

No.  If anything, Emacs has too many default keybindings, making it
more difficult to learn than it would otherwise be.  I'm not arguing for
removing bindings, but I say we should be generally averse to adding new
ones without very good reasons.  I'm trying to get you to argue why there
are very good reasons in this particular case.  Other than saying you
like windmove, you seem loathe to do so.

> > Why is the current state unsatisfactory, and why do you want to make
> > these new bindings?

> Because it's useful to navigate windows positionally as well as
> temporally. Other-window often has unpredictable effects and navigating
> with windmove DWIM.

There are hundreds of other commands it would "be useful to be able to
do".  What is special about windmove, that it should get special
treatment, beyond its current special treatment of being autoloaded?

You haven't answered the first question: why is the current state, where
anybody who wants to can easily use windmove, unsatisfactory?

It's useful to you personally to be able to "navigate windows
positionally", but to me, and likely the majority of Emacs users who
don't use it already, it's not at all useful.

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> >So, currently, windmove is easily available to anybody that wants it,
> >and doesn't "waste" the key bindings of those who don't.
> 
> There is no "waste". We've gone over this at length. People who want to
> bind these keys can bind them still.

Irrelevant.  Users can ALWAYS rebind ANY keys.
That _cannot_ be a reason to bind any particular
key to any particular command by default.

As you say, we've gone over this before.  But
you don't seem to get it.

> Nobody is hurt by default bindings being present,

Everyone is hurt by extraneous, gratuitous,
premature default bindings.

> and all the arguments I've seen against these bindings are
> also arguments against having default bindings at all.

Again, all you have is an all-or-nothing argument.

Adding a given binding by default is a case to
be considered on its own, specific merits.

Not gratuitously adding <whatever> bindings by
default is not at all an argument that there
should be no default bindings.  This really
shouldn't be hard to understand.  Think about it.

Emacs has lots of default bindings.  They were
added conservatively over the long history of
Emacs.  Rarely is a default binding added just
as soon as some new command is added.

And nowadays there are relatively few keys that
are not bound by default - a rare resource.  So
the consideration and deliberation about binding
a new key by default are all the more important -
not to be done eagerly, willy nilly.

The best, and the most frequent approach taken
in Emacs is to add a command with no default
binding, and then see how users use it - how
much, and with what key bindings.  After a long
period providing experience by many users, the
question can be raised about whether, and if so
then which, key to bind to the command.

That just makes sense.  There's no reason to
precipitate the addition of global default
bindings for new commands that we add.

Think about it this way.  Consider the
evolution of the default Emacs UI as a process.
The principle of not eagerly granting default
bindings is just a case of the principle of
_late binding_: retarding the decision to bind
a key until its sure that that's really needed
- really the right thing.

You think you're sure that Emacs should grant
these default key bindings to these commands
RIGHT NOW!!  Let time, and user experience,
and user voices - more voices - decide.

Nothing is lost by taking the "late binding"
approach to such a design decision.  As you
like to say, any user, including you, can
bind the keys you want to these new commands. 

> The point is that out of the box Emacs should
> be useful and useable

Which it is.

> the lack of default bindings for windmove makes
> it less so,

Why do you think so?

If that were the case then windmove should be
turned on as a minor mode, and with these keys
bound in its minor-mode map.  Who would object
to that?  (Why are we even discussing this,
instead of just doing that?)

> there's little downside to adding these bindings.

That's what you don't get.  There's a big
downside to adding these bindings for everyone
NOW.  Come back in a few years with your
arguments.  (Who knows, maybe by then you'll
even have different keys you prefer instead. ;-))

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

> That doesn't clear up all that much.  The answers to "why?" are missing.

To provide keybindings to the windmove commands by default,
i.e. without any configuration on the part of the user.


        Stefan

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Stefan.

On Wed, Jun 26, 2024 at 10:27:44 -0400, Stefan Monnier wrote:
> > That doesn't clear up all that much.  The answers to "why?" are
> > missing.

> To provide keybindings to the windmove commands by default,
> i.e. without any configuration on the part of the user.

What's so special about windmove that it deserves such privileged
treatment?  windmove is already useable with trivial configuration.

I could argue that there are more important features needing key
bindings.  For example, more easily selecting specific frames, or setting
up a frame to use Follow Mode more easily.  Heck, even other-window
really needs a single stroke key binding.

I would expect you to argue back that these features are just my own
personal preferences, and I would accept that.  I am arguing the same
back to you and Daniel - you want to install your personal preferences in
the default key maps.

Neither you nor Daniel has yet given any strong argument why this
particular package is so special.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Daniel Colascione <dancol@dancol.org> writes:

> On June 26, 2024 7:23:38 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Jeremy Bryant <jb@jeremybryant.net>
>>> Cc: Po Lu <luangruo@yahoo.com>,  dancol@dancol.org,  acm@muc.de,
>>>   stefankangas@gmail.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
>>> Date: Tue, 25 Jun 2024 22:26:47 +0100
>>> 
>>> 1.
>>> I also find that C-x 4 is indeed logical, which makes it easier to remember
>>> 
>>> 2.
>>> C-x 4 .. works on the terminal/console.  This is important for
>>> preserving functionality of Emacs.
>>
>>I still hope that someone will tell what is exactly the request here,
>>given that windmove-mode is on by default and its commands are
>>autoloaded.
>
> To be clear, my proposal is to bind C-x 4 <arrow> in the default
> global keymap to the corresponding directional windmove commands and
> to bind the shifted versions of these keys to the state swapping
> versions of these movement commands. IOW, in emacs -Q, C-x 4 LEFT
> should move left.

C-x 4 is not for window management commands, but for commands that
influence which window the results of a future command are to be
displayed in, and it has been so for a substantial period, so that users
won't bat an eyelid before creating bindings keeping to this pattern.
As such, it is perfectly logical to bind, say, ffap-other-window, in
this keymap, but not every command that marginally relates to window
management.

Windmove is not so important as ffap, to judge by the number of
instances of each in the archives of help-gnu-emacs, and therefore
default keybindings for its commands can only be less justified.  If
they were, there could also easily be a place for them far more rational
and less disruptive than C-x 4.  Extending the domain of existing
keymaps is, whatever you think, a source of variance between the
expectations of old and new users, and deprives users of room for custom
keybindings, again, since they experience a natural reluctance to
contradict the judgement of their superiors, expressed in the defaults
they decide, so that the obligation of exercising this privilege wisely
and sparingly devolves on _ourselves_, who should constantly be at pains
to earn and deserve this respect.  With all due respect, you are just
one user, and though many have concurred with your choice, yet none of
them have previously created the same set of bindings as yours.  This
implies that the question of establishing default bindings for Windmove,
and more so your preferences for these bindings, was profoundly
uninteresting to everyone but yourself, and should not even have been
raised until it had attracted some more interest.

So perhaps you might understand why it is upsetting to see our arguments
deflected with some vague dismissal of "general embargoes", or oratory
against "stasis", and appeals to such absolutely irrelevant matters as
Doom Emacs, or because it amounts to declaring that "users ought never
to rebind keys at all."  Reverting to these general proclamations of
triumph gives the impression of being disinterested in constructive
communication and trying to understand your opponents' positions, and
being rather more inclined to simply heckle opponents into silence if
agreement is impossible.  Seriously, ask yourself this simple question,
if the existence of default keybindings are truly no deterrent to
customization, why is cua-mode necessary for the majority of its users,
who simply need C-z rebound to undo and C-x to kill-region?  And why
will the introduction of new keybindings not produce new habits in
users, or, why will such habits not be out of place in sessions where
those key sequences had long been bound otherwise?  But no, we must be
treated to oratory composed of allusions to Doom Emacs, Emacs's need to
remain competitive in the 21st century, and other verbiage.  For shame!

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 26, 2024 9:53:20 AM EDT, Po Lu <luangruo@yahoo.com> wrote:
>Daniel Colascione <dancol@dancol.org> writes:
>
>> On June 26, 2024 7:23:38 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
>>>> From: Jeremy Bryant <jb@jeremybryant.net>
>>>> Cc: Po Lu <luangruo@yahoo.com>,  dancol@dancol.org,  acm@muc.de,
>>>>   stefankangas@gmail.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
>>>> Date: Tue, 25 Jun 2024 22:26:47 +0100
>>>> 
>>>> 1.
>>>> I also find that C-x 4 is indeed logical, which makes it easier to remember
>>>> 
>>>> 2.
>>>> C-x 4 .. works on the terminal/console.  This is important for
>>>> preserving functionality of Emacs.
>>>
>>>I still hope that someone will tell what is exactly the request here,
>>>given that windmove-mode is on by default and its commands are
>>>autoloaded.
>>
>> To be clear, my proposal is to bind C-x 4 <arrow> in the default
>> global keymap to the corresponding directional windmove commands and
>> to bind the shifted versions of these keys to the state swapping
>> versions of these movement commands. IOW, in emacs -Q, C-x 4 LEFT
>> should move left.
>
>C-x 4 is not for window management commands, but for commands that
>influence which window the results of a future command are to be
>displayed in, and it has been so for a substantial period, so that users
>won't bat an eyelid before creating bindings keeping to this pattern.


You're overthinking this. C-x 4 is for stuff relating to windows. Of course that's the right place to put window movement commands. There's no other logical place.

>As such, it is perfectly logical to bind, say, ffap-other-window, in
>this keymap, but not every command that marginally relates to window
>management.

You can choose to make that binding. I don't think it's a good default. Adding a reasonable default does not hurt you.


>
>Windmove is not so important as ffap, to judge by the number of

Ffap is a fringe feature. Window movement is fundamental to the whole system.

>instances of each in the archives of help-gnu-emacs, and therefore
>default keybindings for its commands can only be less justified.  If
>they were, there could also easily be a place for them far more rational
>and less disruptive than C-x 4.  Extending the domain of existing
>keymaps is, whatever you think, a source of variance between the
>expectations of old and new users, and deprives users of room for custom

Again, you're making a general argument against adding any new bindings whatsoever. I don't think that's a good thing. The very same argument would have applied to the vc and project default bindings.

>keybindings, again, since they experience a natural reluctance to
>contradict the judgement of their superiors, expressed in the defaults

So now we're going from keybindings to sociology? K.

>they decide, so that the obligation of exercising this privilege wisely
>and sparingly devolves on _ourselves_, who should constantly be at pains
>to earn and deserve this respect.  With all due respect, you are just
>one user, and though many have concurred with your choice, yet none of
>them have previously created the same set of bindings as yours. 

Yes they have. Check the thread. In fact, it was Stefan who resurrected the thread in the first place.

> This
>implies that the question of establishing default bindings for Windmove,
>and more so your preferences for these bindings, was profoundly
>uninteresting to everyone but yourself, and should not even have been
>raised until it had attracted some more interest.
>
>So perhaps you might understand why it is upsetting to see our arguments
>deflected with some vague dismissal of "general embargoes", or oratory

You are, in fact, though ,making a general argument, then suggesting it applies only to this one matter. That's called "special pleading" and is a structurally invalid kind of discourse.

>against "stasis", and appeals to such absolutely irrelevant matters as
>Doom Emacs, or because it amounts to declaring that "users ought never
>to rebind keys at all."  

I think Doom Emacs and Spacemacs are in bounds. They exist because core Emacs has been insufficiently responsive to needs of real world users, and this thread is this problem in microcosm.

> Reverting to these general proclamations of
>triumph gives the impression of being disinterested in constructive
>communication and trying to understand your opponents' positions, and
>being rather more inclined to simply heckle opponents into silence if
>agreement is impossible.  Seriously, ask yourself this simple question,
>if the existence of default keybindings are truly no deterrent to
>customization, why is cua-mode necessary for the majority of its users,
>who simply need C-z rebound to undo and C-x to kill-region?  And why
>will the introduction of new keybindings not produce new habits in

There is a difference between changing an existing binding (e.g. C-z) and installing a new binding where none currently exists. Merging the two scenarios doesn't lead the conversation in a good place. 

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Daniel Colascione <dancol@dancol.org> writes:

> You're overthinking this. C-x 4 is for stuff relating to windows. Of
> course that's the right place to put window movement commands. There's
> no other logical place.

Who said so?  I see nothing to this effect in ctl-x-4-map or its
(vanishingly scant) documentation, which map is composed entirely of
commands answering to the description I gave.

> You can choose to make that binding. I don't think it's a good
> default. Adding a reasonable default does not hurt you.

It does.  I explained how it does, and you declined to acknowledge my
explanation, or, if you disagreed, openly state your grounds for
disagreement.

> Ffap is a fringe feature. Window movement is fundamental to the whole
> system.

A fringe feature with a VC history thrice as large as windmove's,
and 1.5x as many mentions in help-gnu-emacs.  Window movement is
a fundamental requirement that is perfectly satisfied by other-window
and mouse commands, and the paucity of windmove users speaks for itself,
when they are fewer than those of such a "fringe feature" as ffap.

> Again, you're making a general argument against adding any new
> bindings whatsoever.  I don't think that's a good thing.  The very
> same argument would have applied to the vc and project default
> bindings.

It is a general argument to be _circumspect_ in introducing new
keybindings.  The question of relevance is, Whether a proposed binding
is of sufficient importance or located in a sufficiently discreet
position to nullify the disadvantages cited in the argument.  Windmove
is not, nor are the proposed keybindings.

> So now we're going from keybindings to sociology? K.

What I see is that I argue in good faith and you respond by quibbling
sardonically.  Hardly a shining example of good software development
practice.

>>they decide, so that the obligation of exercising this privilege wisely
>>and sparingly devolves on _ourselves_, who should constantly be at pains
>>to earn and deserve this respect.  With all due respect, you are just
>>one user, and though many have concurred with your choice, yet none of
                       ------------------------------------      -------
>>them have previously created the same set of bindings as yours.
  --------------------------------------------------------------
>
> Yes they have. Check the thread. In fact, it was Stefan who
> resurrected the thread in the first place.

Nowhere has Stefan M mentioned which bindings he personally uses for
Windmove.

> You are, in fact, though ,making a general argument, then suggesting
> it applies only to this one matter.

You are, rather, dealing in absolutes.  I am not responsible for your
failing to understand that, when, where, and how one set of
disadvantages might be outweighed by a corresponding set of advantages.

> That's called "special pleading" and is a structurally invalid kind of
> discourse.

Special pleading is claiming an unsubstantiated exception to a general
rule.  This, by contrast, is the application of a general rule to a
specific issue to which it is material.

> I think Doom Emacs and Spacemacs are in bounds. They exist because
> core Emacs has been insufficiently responsive to needs of real world
> users, and this thread is this problem in microcosm.

More oratory.

> There is a difference between changing an existing binding (e.g. C-z)
> and installing a new binding where none currently exists. Merging the
> two scenarios doesn't lead the conversation in a good place.

It is rather the users who are affected by this distinction than
ourselves.  But you are conflating the scenario where the user creates a
binding in an unoccupied location with that where we do so, after which,
and for the users, that location is removed from the scope of the
former.

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

> C-x 4 is not for window management commands, but for commands that
> influence which window the results of a future command are to be
> displayed in, and it has been so for a substantial period, so that users
> won't bat an eyelid before creating bindings keeping to this pattern.
> As such, it is perfectly logical to bind, say, ffap-other-window, in
> this keymap, but not every command that marginally relates to window
> management.

Since `C-x 4` is the prefix we use for "other window" prefix, what is
the most natural meaning we could give to `C-x 4 <left>`?


        Stefan

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

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

>> C-x 4 is not for window management commands, but for commands that
>> influence which window the results of a future command are to be
>> displayed in, and it has been so for a substantial period, so that users
>> won't bat an eyelid before creating bindings keeping to this pattern.
>> As such, it is perfectly logical to bind, say, ffap-other-window, in
>> this keymap, but not every command that marginally relates to window
>> management.
>
> Since `C-x 4` is the prefix we use for "other window" prefix, what is
> the most natural meaning we could give to `C-x 4 <left>`?
>
>
>         Stefan

Whatever it is that C-x 4 4 C-x <left> does.

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Stefan.

On Wed, Jun 26, 2024 at 10:27:31 -0400, Stefan Monnier wrote:
> > C-x 4 is not for window management commands, but for commands that
> > influence which window the results of a future command are to be
> > displayed in, and it has been so for a substantial period, so that users
> > won't bat an eyelid before creating bindings keeping to this pattern.
> > As such, it is perfectly logical to bind, say, ffap-other-window, in
> > this keymap, but not every command that marginally relates to window
> > management.

> Since `C-x 4` is the prefix we use for "other window" prefix, what is
> the most natural meaning we could give to `C-x 4 <left>`?

previous-buffer-other-window, of course.  It might even be quite a
useful command.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Augusto Stoffel]

On Wed, 26 Jun 2024 at 10:27, Stefan Monnier wrote:

>> C-x 4 is not for window management commands, but for commands that
>> influence which window the results of a future command are to be
>> displayed in, and it has been so for a substantial period, so that users
>> won't bat an eyelid before creating bindings keeping to this pattern.
>> As such, it is perfectly logical to bind, say, ffap-other-window, in
>> this keymap, but not every command that marginally relates to window
>> management.
>
> Since `C-x 4` is the prefix we use for "other window" prefix, what is
> the most natural meaning we could give to `C-x 4 <left>`?
>
>
>         Stefan

Juri gave a well-founded answered to this question in this thread on
Monday.

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> Windmove is not so important as ffap, to judge by the number of
> instances of each in the archives of help-gnu-emacs, and therefore
> default keybindings for its commands can only be less justified.

I fear your analogy/comparison with ffap might be
lost on some readers.

The point, I think, is that ffap DOES NOT just force
(what it considers to be its) default bindings on users.

What does it do?  It puts a list of `global-set-key'
forms in a variable, `ffap-bindings'.  And then it
defines a command, `ffap-bindings', that evaluates
the variable, creating the bindings.

What's more, ffap is polite enough to say this in the
doc string of variable `ffap-bindings':

 "List of binding forms evaluated by function `ffap-bindings'.
 A reasonable ffap installation needs just this one line:
   (ffap-bindings)
 Of course if you do not like these bindings, just roll your own!"

That's a clean approach.  Alternatively, use a minor
mode.  And maybe a defcustom instead of a defvar for
the bindings.  (`ffap.el' was written long, long ago.)

Re: Proposal: new default bindings for winner and windmove

[Visuwesh]

[ஞாயிறு ஜூன் 23, 2024] Eli Zaretskii wrote:

> [..]
> It is clear that Daniel thought years ago we should have key bindings
> for windmove, and still thinks so, and Stefan Monnier agrees with him.
> It is also clear that Alan and Po Lu think we shouldn't.  Now let's
> hear from others, and please leave it to the Emacs maintainers to
> decide what to do with this after we've heard enough opinions.

I usually do not have enough windows open to warrant a better
keybinding/command than C-x o with repeat-mode enabled.  If I do, I have
three columns of windows (some dedicated) and in these times, I find it
better to use the touchpad with mouse-autoselect-window enabled.  I am
not sure if I will ever use C-x 4 ARROW given the length compared with
C-x o though, even with a repeat-map.  OTOH, I think I will use a
shorter keybinding for C-- C-x o, maybe C-x O.

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 23, 2024 10:15:59 AM EDT, Po Lu <luangruo@yahoo.com> wrote:
>Daniel Colascione <dancol@dancol.org> writes:
>
>> I don't trust that many such users exist, and even if they did,
>> providing default keybindings for these keys will not somehow override
>> the keybindings you install yourself.
>
>Sure.  And more users stand to benefit from Windmove commands if they
>are bound to C-x 4, than if they were required to bind such commands
>themselves, commands defined by a package that is already of marginal
>interest?  What extraordinary logic!

Well, yes? It's of marginal interest because it's not discoverable. It's nevertheless useful. More people would use the package if it were discoverable. I don't think the logic is terribly complicated here.


>> This attitude is why Doom Emacs exists. A live software project is one
>> that changes. A dead one prioritizes stasis over user experience.
>
>Since Doom Emacs exists and is Free Software, why are users not at
>liberty to install it and bid farewell to reaction and "stasis" in Emacs
>development?  And why is it a matter for our consideration whether we
>fail or succeed in competing with them?  Any mention of "competition"
>with an Emacs package is already a contradiction in terms.

It continues to astound me that people want to put many hours into a project yet insist they're indifferent between its success and failure.

>> Nothing we're talking about here will disturb your custom
>> keybindings. Your experience will work just as it did before. The only
>> difference is that users who don't have custom bindings for the arrow
>> keys under C-x 4 will get windmove functionality if they don't
>> customize the bindings.
>
>Spoken like a true intellectual, in the face of a real-life example to
>the contrary.

I'm waiting for such an example. You've bound C-x 4 down to something. Fine. That binding would continue to work if Emacs came with C-x 4 already bound to something else. That's how defaults work. Can you please explain the actual problem that providing these new default bindings would cause for your workflow?

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Daniel Colascione <dancol@dancol.org> writes:

> Well, yes? It's of marginal interest because it's not
> discoverable. It's nevertheless useful. More people would use the
> package if it were discoverable. I don't think the logic is terribly
> complicated here.

C-x 4 <up> is more discoverable than is (emacs)Window Convenience?  That
is an exceptional statement that calls for exceptional evidence.

> It continues to astound me that people want to put many hours into a
> project yet insist they're indifferent between its success and
> failure.

How does the success or failure of an _Emacs_ package (Doom Emacs)
produce the opposite outcome for Emacs?  If anything I would expect it
to be our duty to wish and help them achieve success, and never to treat
them as adversaries.

> I'm waiting for such an example. You've bound C-x 4 down to
> something. Fine. That binding would continue to work if Emacs came
> with C-x 4 already bound to something else. That's how defaults
> work. Can you please explain the actual problem that providing these
> new default bindings would cause for your workflow?

The next user who drops by my computer types C-x 4 down and finds
himself staring at an open web browser, Emacs nowhere in sight.

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 23, 2024 10:37:12 AM EDT, Po Lu <luangruo@yahoo.com> wrote:
>Daniel Colascione <dancol@dancol.org> writes:
>
>> Well, yes? It's of marginal interest because it's not
>> discoverable. It's nevertheless useful. More people would use the
>> package if it were discoverable. I don't think the logic is terribly
>> complicated here.
>
>C-x 4 <up> is more discoverable than is (emacs)Window Convenience?  That
>is an exceptional statement that calls for exceptional evidence.
>
>> It continues to astound me that people want to put many hours into a
>> project yet insist they're indifferent between its success and
>> failure.
>
>How does the success or failure of an _Emacs_ package (Doom Emacs)
>produce the opposite outcome for Emacs?  If anything I would expect it
>to be our duty to wish and help them achieve success, and never to treat
>them as adversaries.
>
>> I'm waiting for such an example. You've bound C-x 4 down to
>> something. Fine. That binding would continue to work if Emacs came
>> with C-x 4 already bound to something else. That's how defaults
>> work. Can you please explain the actual problem that providing these
>> new default bindings would cause for your workflow?
>
>The next user who drops by my computer types C-x 4 down and finds
>himself staring at an open web browser, Emacs nowhere in sight.

So you think users should be prevented from changing default keybindings? That's what the logic of your argument suggests. 

In practice, nobody but me is realistically going to be using my Emacs configuration. Personal specificity is the essence of personalization. Most random people sitting down to an Emacs session anyway are going to try things like C-c to copy and C-v to paste, and these don't work anyway.

Re: Proposal: new default bindings for winner and windmove

[Joel Reicher]

Daniel Colascione <dancol@dancol.org> writes:

> On June 23, 2024 10:15:59 AM EDT, Po Lu <luangruo@yahoo.com> 
> wrote:
>>Daniel Colascione <dancol@dancol.org> writes:
>>
>>> I don't trust that many such users exist, and even if they 
>>> did, providing default keybindings for these keys will not 
>>> somehow override the keybindings you install yourself.
>>
>>Sure.  And more users stand to benefit from Windmove commands if 
>>they are bound to C-x 4, than if they were required to bind such 
>>commands themselves, commands defined by a package that is 
>>already of marginal interest?  What extraordinary logic!
>
> Well, yes? It's of marginal interest because it's not 
> discoverable. It's nevertheless useful. More people would use 
> the package if it were discoverable. I don't think the logic is 
> terribly complicated here.

What I have found as I've learned Emacs is that while 
discoverability is important, what I've really needed is 
"try-ability", as it's often been difficult for me to imagine how 
a particular function might feel to use, might serve me (or not), 
and sometimes what it even does until I see it (especially if it 
involves new concepts).

A few times early on I would have liked default keybindings 
automatically added /after/ electing to try a package and /only 
if/ those keys weren't already bound to something else. Every now 
and again I think Emacs would be improved by having this-or-that 
feature with a lower "barrier to trying", even if I had elected 
not to stick with it.

These days I'm confident in my ability to add my own keybindings 
in order to try a package, but at the start I wasn't.

Thanks and regards,

       - Joel

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

>> Scarce are the keys that are not bound by default...
>
> This attitude is why Doom Emacs exists.

That may be.  It may also be why this or that
package exists, which users can _optionally_
use, and which might define any (or all!) of
the remaining keys that Emacs doesn't bind
by default.

Using Doom or such a package is a user _choice_.
Emacs doesn't, and it shouldn't, make such a
choice (regarding default behavior) for users.

If you want to do more than just let each user
decide whether to bind these new commands, and
if so, to which keys, then just provide users a
little package/mode that binds them.  Don't try
to make Emacs itself impose such behavior by
default.  Not till a lot of time and experience
have shown what users actually think/do/want.

> A live software project is one that changes.

Emacs is alive and well, and changing (quicker
than ever).

Don't confuse how you want Emacs to change
immediately with how Emacs should change now.
 
> The only difference is that users who don't
> have custom bindings for the arrow keys under
> C-x 4 will get windmove functionality if they
> don't customize the bindings.

I'd hope that even the use of windmove (a good
addition to Emacs) would be _optional_.  If
the question is to not only add windmove now
but make its use mandatory, then we're really
heading down the wrong path - precipitously.

I doubt that's the case.  At least I hope it's
not

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 23, 2024 9:40:06 AM EDT, Po Lu <luangruo@yahoo.com> wrote:
>Daniel Colascione <dancol@dancol.org> writes:
>
>> So? Nobody is preventing those users doing what they want with their
>> key bindings.  You're making a general purpose argument against having
>> default key bindings at all. Why don't we just ship Emacs with an
>> empty global keymap so we're not imposing on anyone?
>
>Replace "having" with "introducing" and you should find that this line
>of argument is generally sound.  After all these years, all the commands
>that justify being bound by default have already received bindings in
>the default keymaps, and plenty of commands that are well in excess of
>this criterion.
>
>> Metrics with nontrivial opt-in suffer from selection bias. The sort of
>> person who goes out of his way to enable telemetry is the sort of
>> person who's going to do more customization than the average user.
>
>Yes.  That does not render mandatory collection of metrics any the less
>morally objectionable in a computer program, nor imposing arbitrary
>changes on users any more reasonable.
>

Opt-out collection of anonymous metrics has been an industry standard for many years now. There's nothing morally objectionable about it. It's perfectly normal. Nor would there be anything about asking users "Collect anonymous metrics to help Emacs development? Y/N" on first startup. Suggesting that asking such a question is a moral wrong is an extreme and uncommon position.

Telemetry, opt-in,opt-out [was: Proposal: new default bindings for winner and windmove]

[tomas]

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

On Sun, Jun 23, 2024 at 09:48:26AM -0400, Daniel Colascione wrote:

[snipped CC a bit]

[...]

> Opt-out collection of anonymous metrics has been an industry standard for many years now.

Whatever "industry standard" means. Industry standard is
surveillance capitalism these days. Not something to strive
for, not in free software's context, I think.

Cheers
-- 
tomás

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

Re: Telemetry, opt-in,opt-out [was: Proposal: new default bindings for winner and windmove]

[Daniel Colascione]

On June 23, 2024 10:14:36 AM EDT, tomas@tuxteam.de wrote:
>On Sun, Jun 23, 2024 at 09:48:26AM -0400, Daniel Colascione wrote:
>
>[snipped CC a bit]
>
>[...]
>
>> Opt-out collection of anonymous metrics has been an industry standard for many years now.
>
>Whatever "industry standard" means. Industry standard is
>surveillance capitalism these days. Not something to strive
>for, not in free software's context, I think.
>
>Cheers

Nothing to do with free software. A free program that collects anonymized usage metrics is still free. The simple fact is that the more you learn about your users's preferences, the better you can satisfy their desires. As long as users can opt out, I see no moral quandary whatsoever, especially if the program explicitly asks the user about anonymized data collection on first startup.

Re: Telemetry, opt-in,opt-out [was: Proposal: new default bindings for winner and windmove]

[Stefan Kangas]

Daniel Colascione <dancol@dancol.org> writes:

>>Whatever "industry standard" means. Industry standard is
>>surveillance capitalism these days. Not something to strive
>>for, not in free software's context, I think.
>
> Nothing to do with free software. A free program that collects
> anonymized usage metrics is still free. The simple fact is that the
> more you learn about your users's preferences, the better you can
> satisfy their desires. As long as users can opt out, I see no moral
> quandary whatsoever, especially if the program explicitly asks the
> user about anonymized data collection on first startup.

This might not be spelled out in the GNU GPL, but it is definitely an
issue that has concerned the Free Software movement.

You might not care strongly about this, but other people do.  We should
respect those users, and thus make any type of metrics opt-in.  IMO,
Debian's popcon gets this right: it's opt-in, and the statistics can be
reasonably anonymized by sending them over Tor.

If anyone wants to work on something like this, please be aware that
this is very likely going to be the bare minimum for us to be able to
accept it.  Thanks.

Re: Telemetry, opt-in,opt-out [was: Proposal: new default bindings for winner and windmove]

[tomas]

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

On Sun, Jun 23, 2024 at 08:23:19AM -0700, Stefan Kangas wrote:

[...]

> You might not care strongly about this, but other people do.  We should
> respect those users, and thus make any type of metrics opt-in.  IMO,
> Debian's popcon gets this right: it's opt-in, and the statistics can be
> reasonably anonymized by sending them over Tor.

Thank you.

Cheers
-- 
tomás

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

Re: Telemetry, opt-in,opt-out [was: Proposal: new default bindings for winner and windmove]

[Stefan Monnier]

>> Opt-out collection of anonymous metrics has been an industry standard
>> for many years now.
> Whatever "industry standard" means. Industry standard is
> surveillance capitalism these days. Not something to strive
> for, not in free software's context, I think.

Yup, I'd be happy to see some kind of statistics-gathering system
included in Emacs if it can help us decide how to evolve the projects
and its default settings, but it definitely needs to be opt-in: Emacs
should never contact a host without the user "explicitly" requesting it
(there's some wiggle room about what "explicitly" can mean, admittedly,
but in terms of sending telemetry it's pretty clear to me that it needs
to be opt-in).


        Stefan

RE: [External] : Re: Telemetry, opt-in,opt-out [was: Proposal: new default bindings for winner and windmove]

[Drew Adams]

> >> Opt-out collection of anonymous metrics has been an industry standard
> >> for many years now.
> > Whatever "industry standard" means. Industry standard is
> > surveillance capitalism these days. Not something to strive
> > for, not in free software's context, I think.
> 
> Yup, I'd be happy to see some kind of statistics-gathering system
> included in Emacs if it can help us decide how to evolve the projects
> and its default settings, but it definitely needs to be opt-in: Emacs
> should never contact a host without the user "explicitly" requesting it
> (there's some wiggle room about what "explicitly" can mean, admittedly,
> but in terms of sending telemetry it's pretty clear to me that it needs
> to be opt-in).

It's also possible to just ask users - poll them,
as RMS often suggests.

Neither polls nor opt-in telemetry are without
their limitations/problems, of course.  But the
point is that, if and when Emacs dev wants to
consider whether to add some default key bindings,
it can help to get input from the wider user base.

Re: [External] : Re: Telemetry, opt-in, opt-out [was: Proposal: new default bindings for winner and windmove]

[Madhu]

* Drew Adams <SJ0PR10MB54880D01DCA0FCB66755CB81F3CB2@SJ0PR10MB5488.namprd10.prod.outlook.com> :
Wrote on Sun, 23 Jun 2024 21:12:34 +0000:
>> >> Opt-out collection of anonymous metrics has been an industry standard
>> >> for many years now.
>> > Whatever "industry standard" means. Industry standard is
>> > surveillance capitalism these days. Not something to strive
>> > for, not in free software's context, I think.
>> Yup, I'd be happy to see some kind of statistics-gathering system
>> included in Emacs if it can help us decide how to evolve the projects
>> and its default settings, but it definitely needs to be opt-in: Emacs
>> should never contact a host without the user "explicitly" requesting it
>> (there's some wiggle room about what "explicitly" can mean, admittedly,
>> but in terms of sending telemetry it's pretty clear to me that it needs
>> to be opt-in).
>
> It's also possible to just ask users - poll them,
> as RMS often suggests.
>
> Neither polls nor opt-in telemetry are without
> their limitations/problems, of course.  But the
> point is that, if and when Emacs dev wants to
> consider whether to add some default key bindings,
> it can help to get input from the wider user base.

But with telemetry there is data which can be passed-off as non-biased
and international investors can control the development of emacs based
on the numbers (backed by solid evidence)

RE: [External] : Re: Telemetry, opt-in, opt-out [was: Proposal: new default bindings for winner and windmove]

[Drew Adams]

> > It's also possible to just ask users - poll them,
> > as RMS often suggests.
> >
> > Neither polls nor opt-in telemetry are without
> > their limitations/problems, of course.  But the
> > point is that, if and when Emacs dev wants to
> > consider whether to add some default key bindings,
> > it can help to get input from the wider user base.
> 
> But with telemetry there is data which can be
> passed-off as non-biased and international
> investors can control the development of emacs
> based on the numbers (backed by solid evidence)

lol!

Re: [External] : Re: Telemetry, opt-in, opt-out [was: Proposal: new default bindings for winner and windmove]

[Dr. Arne Babenhauserheide via Emacs development discussions.]

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

Madhu <enometh@meer.net> writes:

> * Drew Adams <SJ0PR10MB54880D01DCA0FCB66755CB81F3CB2@SJ0PR10MB5488.namprd10.prod.outlook.com> :
> Wrote on Sun, 23 Jun 2024 21:12:34 +0000:
>>> >> Opt-out collection of anonymous metrics has been an industry standard
>>> >> for many years now.
>>> > Whatever "industry standard" means. Industry standard is
>>> > surveillance capitalism these days. Not something to strive
>>> > for, not in free software's context, I think.
>>> Yup, I'd be happy to see some kind of statistics-gathering system
>>> included in Emacs if it can help us decide how to evolve the projects
>>> and its default settings, but it definitely needs to be opt-in: Emacs
>>> should never contact a host without the user "explicitly" requesting it
>>> (there's some wiggle room about what "explicitly" can mean, admittedly,
>>> but in terms of sending telemetry it's pretty clear to me that it needs
>>> to be opt-in).
>>
>> It's also possible to just ask users - poll them,
>> as RMS often suggests.
>
> But with telemetry there is data which can be passed-off as non-biased
> and international investors can control the development of emacs based
> on the numbers (backed by solid evidence)

That is a strong argument against telemetry.
And a beautiful take-down of the industry standard on surveillance.

I guess that’s how you intended it :-)

Best wishes,
Arne

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

Re: [External] : Re: Telemetry, opt-in, opt-out [was: Proposal: new default bindings for winner and windmove]

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

  > But with telemetry there is data which can be passed-off as non-biased
  > and international investors can control the development of emacs based
  > on the numbers (backed by solid evidence)

I think that it is ok to have a kind of telemetry feature, but for
privacy's sake it should ask the user to confirm transmission just
before sending any data.

At that point, it should describe in a clear way what data will be sent.

It doesn't need to be totally precise about tiny details of what data,
but should give enough info that the yser can see what privacy
implications there could be.

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

Re: Telemetry, opt-in,opt-out [was: Proposal: new default bindings for winner and windmove]

[Ihor Radchenko]

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

>>> Opt-out collection of anonymous metrics has been an industry standard
>>> for many years now.
>> Whatever "industry standard" means. Industry standard is
>> surveillance capitalism these days. Not something to strive
>> for, not in free software's context, I think.
>
> Yup, I'd be happy to see some kind of statistics-gathering system
> included in Emacs if it can help us decide how to evolve the projects
> and its default settings, but it definitely needs to be opt-in: Emacs
> should never contact a host without the user "explicitly" requesting it
> (there's some wiggle room about what "explicitly" can mean, admittedly,
> but in terms of sending telemetry it's pretty clear to me that it needs
> to be opt-in).

Note that I have done an opt-in statistics gathering in
https://elpa.gnu.org/packages/emacs-gc-stats.html

Here are some privacy-related things that have been considered:

1. opt-in only, and implemented as global minor mode, so that people can
   disable statistics gathering any time, and re-enable later

2. Data is in plain text format for easier review

3. Data is not sent automatically. Only user decides when to send it
   (several users asked for a reminder about sending though)
   A note: I did this via mailing list, so it was not exactly anonymous,
   but submissions may be made anonymous as well, with appropriate
   upload server like 0x0 or similar (but hosted by FSF).

4. What is recorded is documented. And can be customized.

5. Data recorded during current Emacs session can be discarded any time,
   with a command.

I had no major complaints about privacy, except one instance of Emacs
user whose employer had strict data sharing policy. Of course, that user
did not have to opt in.

(note that the package itself is rather data-agnostic and can be re-used
to collect something else, not just GC statistics)


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Telemetry, opt-in,opt-out [was: Proposal: new default bindings for winner and windmove]

[tomas]

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

On Fri, Jun 28, 2024 at 05:28:04AM +0000, Ihor Radchenko wrote:

[...]

> Here are some privacy-related things that have been considered:

[...]

Exemplary, thanks.

Cheers
-- 
t

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

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Daniel Colascione <dancol@dancol.org> writes:

> Opt-out collection of anonymous metrics has been an industry standard
> for many years now. There's nothing morally objectionable about
> it. It's perfectly normal.

Proprietary software is also an industry standard, and it is equally,
no, yet more normal.  Whether you agree that it is morally objectionable
or no, it is one of the fundamental tenets of the creed of the Free
Software movement, of which the GNU Project is a prominent element.

Child labor, you will find, was also the norm in the cradle of the
Industrial Revolution (doubtless an industry standard!), and the slave
trade was a remarkably profitable venture for many a merchant till the
1900s.

And I certainly find objectionable software that connects to the
Internet without my informed consent.

> Nor would there be anything about asking users "Collect anonymous
> metrics to help Emacs development? Y/N" on first startup.

This is by definition "opt-in", which produces results that, by your own
admission, are totally meaningless.  It would also be irritating.

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 23, 2024 10:25:29 AM EDT, Po Lu <luangruo@yahoo.com> wrote:
>Daniel Colascione <dancol@dancol.org> writes:
>
>> Opt-out collection of anonymous metrics has been an industry standard
>> for many years now. There's nothing morally objectionable about
>> it. It's perfectly normal.
>
>Child labor

That escalated quickly.

>
>And I certainly find objectionable software that connects to the
>Internet without my informed consent.
>
>> Nor would there be anything about asking users "Collect anonymous
>> metrics to help Emacs development? Y/N" on first startup.
>
>This is by definition "opt-in", which produces results that, by your own
>admission, are totally meaningless.  

It's more "forced choice" than opt-in, same as recently-required browser choice screens in EU countries. IMHO opt-out is also good enough, but I'd be happy with this forced choice too. I don't think an out-of-the-way pure opt-in option would collect enough unbiased usage data. The conversion funnel narrows rapidly as friction increases.

> It would also be irritating.

It's one key, once, ever.

Re: Proposal: new default bindings for winner and windmove

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Daniel Colascione <dancol@dancol.org> writes:
>
>> So? Nobody is preventing those users doing what they want with their
>> key bindings.  You're making a general purpose argument against having
>> default key bindings at all. Why don't we just ship Emacs with an
>> empty global keymap so we're not imposing on anyone?
>
> Replace "having" with "introducing" and you should find that this line
> of argument is generally sound.  After all these years, all the commands
> that justify being bound by default have already received bindings in
> the default keymaps, and plenty of commands that are well in excess of
> this criterion.

We are not going to impose a general embargo on new keybindings.
This idea has been proposed and rejected in the past.

So we will have to consider every proposal individually.  This might
include some amount of bikeshedding.  Sorry.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 23 Jun 2024 08:24:55 -0700
> Cc: Alan Mackenzie <acm@muc.de>, Stefan Monnier <monnier@iro.umontreal.ca>,
>  emacs-devel@gnu.org
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Daniel Colascione <dancol@dancol.org> writes:
> >
> >> So? Nobody is preventing those users doing what they want with their
> >> key bindings.  You're making a general purpose argument against having
> >> default key bindings at all. Why don't we just ship Emacs with an
> >> empty global keymap so we're not imposing on anyone?
> >
> > Replace "having" with "introducing" and you should find that this line
> > of argument is generally sound.  After all these years, all the commands
> > that justify being bound by default have already received bindings in
> > the default keymaps, and plenty of commands that are well in excess of
> > this criterion.
> 
> We are not going to impose a general embargo on new keybindings.
> This idea has been proposed and rejected in the past.

It is a silly idea, forgive my French.  Because Daniel is right:
anyone who already binds the offending keys to some commands will not
be affected by the default binding.  The only case where the default
binding can affect someone is if we _change_ an existing default
binding.  This is not such a case.

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> Scarce are the keys that are not bound by default,

Hard to believe that this needs to be pointed out
to people, but yes, of course.  100 times this.

Scarce resources.  Not to be spent gratuitously.
 

Re: Proposal: new default bindings for winner and windmove

[Gregor Zattler]

Hi Po Lu,
* Po Lu <luangruo@yahoo.com> [2024-06-23; 21:40 +08]:
> Scarce are the keys that are not bound by default, and therefore may be
> customized by users without risking departures in their Emacs sessions
> from the expectations of users trained and pastured on uncustomized
> sessions.  This is just one, and by far not the most compelling, of many
> objections to introducing new default keybindings, but one of which a
> recent example comes to mind: C-x x u has for many years been bound in
> my sessions to a command that deletes a buffer's undo list, usually in
> the interests of security.  The consequences of a stranger's
> unsuspectingly typing the same to invoke rename-uniquely might easily
> have been catastrophic.

why would strangers type anything in
your (resp my) personally customized
emacs session?

I wouldn't want that to happen.

Regards, Gregor

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Daniel.

On Sun, Jun 23, 2024 at 08:57:36 -0400, Daniel Colascione wrote:


> On June 23, 2024 8:05:22 AM EDT, Alan Mackenzie <acm@muc.de> wrote:
> >On Sun, Jun 23, 2024 at 07:14:25 -0400, Daniel Colascione wrote:
> >> On June 23, 2024 6:05:13 AM EDT, Alan Mackenzie <acm@muc.de> wrote:

> >> >On Fri, Jun 21, 2024 at 15:39:09 -0500, Stefan Kangas wrote:
> >> >> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >> >> > A few years ago, Daniel suggested:
> >> >> >> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
> >> >> >> for people automatically, enabled by default.

> >> >> > AFAICT we still don't actually provide any keybindings for the windmove
> >> >> > commands by default.  Did I miss a controversy about that, or did it
> >> >> > just fall through the cracks?

> >> >> FWIW, I don't remember any controversy either, so my guess is that it
> >> >> just fell through the cracks.

> >> >I would be against using C-x 4 <arrow keys> or C-x 5 <arrow-keys> for
> >> >windmove (or anything else) by default.  Key sequences with arrow keys
> >> >are too few, and too precious, to use for anything not critically
> >> >important.

> >> >windmove is not critically important.  Either it isn't used at all by a
> >> >user (likely most users), or it is used all the time (by a small number
> >> >of users).  In the latter case, the user will already have bound the
> >> >commands to key sequences, since they are not useful called from M-x.

> >> >It wasn't so long ago that we were removing default key bindings so as
> >> >to free them up for other uses.  I don't think there's any reason to
> >> >reverse that policy for windmove.  It just isn't important enough.

> >> >There will be users who've bound these key bindings for their own uses.
> >> >Let's not mess these users around.

> >> The arrow keys don't have any meaning after C-x 4 today, and the
> >> meaning I've been wanting to give them is useful and logical.

> >It's useful to you, personally.  It wouldn't be useful to me.

> >> I've been using the arrow key setup for years locally and it works very
> >> well. It really does make window management much less annoying, and
> >> it's not like we're going to use the arrow keys for anything else under
> >> C-x 4.

> >You've been using C-x 4 <arrow key> for your purposes, and other users
> >will be using them for their purposes, likely to be different from yours.

> So? Nobody is preventing those users doing what they want with their
> key bindings.  You're making a general purpose argument against having
> default key bindings at all. Why don't we just ship Emacs with an empty
> global keymap so we're not imposing on anyone?

That isn't a nuanced reasoned argument any more than it was the first
time you made it (which I snipped).  It's barely worth replying to.

What I'm saying is that IN THIS PARTICULAR CASE binding those particular
keys to these commands is not a good idea.

[ .... ]

> >> But that aside, even if windmove is sparsely used today, might that be
> >> because it's inconvenient to use without bindings?

> >It might, but it's unlikely.  Even C-x 4 <up> would be inconvenient for
> >me.  I have other-window bound to <f12> and rarely have more than three
> >or four windows in a frame.  I'd hit <f12> two or three times rather
> >going through the rigmarole of C-x 4 <up>.

> So? How does providing default windmove bindings make your life worse?

It clutters up the keymap with rarely[*] used commands, leaving fewer
bindings available to the user.
[*] That's "rarely" as in "very few users" even though each of these no
doubt uses the commands a lot.

> >As I said, C-x 4 <arrow keys> are convenient to you for windmove
> >commands.  They'll be convenient to other users for other commands in
> >just the same way.  You're proposing imposing your setup on everybody.
> >I'm against this.

> They're not convenient for anyone if left unbound. 

This is convenient for anybody who, like you, has already bound these
keys to commands, and to users who are looking for key sequences for
their new commands.

There are lots of things in Emacs which seemed like good ideas at the
time, but never really took off and became popular.  windmove seems to be
one of these.  I have some similarly useful commands in my .emacs without
which I could hardly use Emacs, but which I don't try to impose on
other users.  We shouldn't be filling up unused key bindings with such
commands.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 23, 2024 9:59:05 AM EDT, Alan Mackenzie <acm@muc.de> wrote:
>Hello, Daniel.
>
>On Sun, Jun 23, 2024 at 08:57:36 -0400, Daniel Colascione wrote:
>
>
>> On June 23, 2024 8:05:22 AM EDT, Alan Mackenzie <acm@muc.de> wrote:
>> >On Sun, Jun 23, 2024 at 07:14:25 -0400, Daniel Colascione wrote:
>> >> On June 23, 2024 6:05:13 AM EDT, Alan Mackenzie <acm@muc.de> wrote:
>
>> >> >On Fri, Jun 21, 2024 at 15:39:09 -0500, Stefan Kangas wrote:
>> >> >> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> >> >> > A few years ago, Daniel suggested:
>> >> >> >> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
>> >> >> >> for people automatically, enabled by default.
>
>> >> >> > AFAICT we still don't actually provide any keybindings for the windmove
>> >> >> > commands by default.  Did I miss a controversy about that, or did it
>> >> >> > just fall through the cracks?
>
>> >> >> FWIW, I don't remember any controversy either, so my guess is that it
>> >> >> just fell through the cracks.
>
>> >> >I would be against using C-x 4 <arrow keys> or C-x 5 <arrow-keys> for
>> >> >windmove (or anything else) by default.  Key sequences with arrow keys
>> >> >are too few, and too precious, to use for anything not critically
>> >> >important.
>
>> >> >windmove is not critically important.  Either it isn't used at all by a
>> >> >user (likely most users), or it is used all the time (by a small number
>> >> >of users).  In the latter case, the user will already have bound the
>> >> >commands to key sequences, since they are not useful called from M-x.
>
>> >> >It wasn't so long ago that we were removing default key bindings so as
>> >> >to free them up for other uses.  I don't think there's any reason to
>> >> >reverse that policy for windmove.  It just isn't important enough.
>
>> >> >There will be users who've bound these key bindings for their own uses.
>> >> >Let's not mess these users around.
>
>> >> The arrow keys don't have any meaning after C-x 4 today, and the
>> >> meaning I've been wanting to give them is useful and logical.
>
>> >It's useful to you, personally.  It wouldn't be useful to me.
>
>> >> I've been using the arrow key setup for years locally and it works very
>> >> well. It really does make window management much less annoying, and
>> >> it's not like we're going to use the arrow keys for anything else under
>> >> C-x 4.
>
>> >You've been using C-x 4 <arrow key> for your purposes, and other users
>> >will be using them for their purposes, likely to be different from yours.
>
>> So? Nobody is preventing those users doing what they want with their
>> key bindings.  You're making a general purpose argument against having
>> default key bindings at all. Why don't we just ship Emacs with an empty
>> global keymap so we're not imposing on anyone?
>
>That isn't a nuanced reasoned argument any more than it was the first
>time you made it (which I snipped).  It's barely worth replying to.

Your position neverthelessboils down to a general argument against introducing new default keybindings, because...

>What I'm saying is that IN THIS PARTICULAR CASE binding those particular
>keys to these commands is not a good idea.

...I haven't seen why in this case binding these keys is a particularly bad idea. The original argument is that providing these bindings would somehow override user customization. They won't. There's no deprivation of user customization, so the "scarcity" of arrow key bindings is irrelevant. Now the objection is over "clutter"? Does an arrow key binding somehow create more clutter than some other binding? There's nothing special about these bindings.


>
>[ .... ]
>
>> >> But that aside, even if windmove is sparsely used today, might that be
>> >> because it's inconvenient to use without bindings?
>
>> >It might, but it's unlikely.  Even C-x 4 <up> would be inconvenient for
>> >me.  I have other-window bound to <f12> and rarely have more than three
>> >or four windows in a frame.  I'd hit <f12> two or three times rather
>> >going through the rigmarole of C-x 4 <up>.
>
>> So? How does providing default windmove bindings make your life worse?
>
>It clutters up the keymap with rarely[*] used commands, leaving fewer
>bindings available to the user.
>[*] That's "rarely" as in "very few users" even though each of these no
>doubt uses the commands a lot.

That a command without a binding might (or might not --- no metrics) rarely used and therefore doesn't merit a binding is kind of tautological.

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> So? Nobody is preventing those users doing what they want with their key
> bindings.  You're making a general purpose argument against having default
> key bindings at all.

No.  He made a general-purpose argument for not
introducing NEW default bindings gratuitously.

> Why don't we just ship Emacs with an empty global
> keymap so we're not imposing on anyone?

Straw-man argument.  The default bindings in Emacs
were adopted after years of practice, not willy
nilly each time a new command was added.

If each time a command is added someone pipes up
saying that it should be given a default binding,
and that any questioning of that is tantamount to
arguing against Emacs having ANY default bindings,
then we've truly landed in RidiculousLand.

> > As I said, C-x 4 <arrow keys> are convenient to
> > you for windmove commands.  They'll be convenient
> > to other users for other commands in just the
> > same way.  You're proposing imposing your setup
> > on everybody.  I'm against this.
> 
> They're not convenient for anyone if left unbound.

Left unbound _by default_ is not the same as left
unbound.  User can -- and no doubt WILL -- bind
such commands if they use them.  We can check in a
few years to see what the actual practice is, and
THEN argue over whether to give them default
bindings, and if so, which bindings.

Nothing is lost, and much is gained, by not giving
these new commands default bindings.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> Date: Sun, 23 Jun 2024 10:05:13 +0000
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>  Daniel Colascione <dancol@dancol.org>, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello, Stefan and Stefan.
> 
> On Fri, Jun 21, 2024 at 15:39:09 -0500, Stefan Kangas wrote:
> > Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > > A few years ago, Daniel suggested:
> > >> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
> > >> for people automatically, enabled by default.
> > >
> > > AFAICT we still don't actually provide any keybindings for the windmove
> > > commands by default.  Did I miss a controversy about that, or did it
> > > just fall through the cracks?
> 
> > FWIW, I don't remember any controversy either, so my guess is that it
> > just fell through the cracks.
> 
> I would be against using C-x 4 <arrow keys> or C-x 5 <arrow-keys> for
> windmove (or anything else) by default.  Key sequences with arrow keys
> are too few, and too precious, to use for anything not critically
> important.

I'm not sure we all are on the same page regarding what is being
proposed.  For that matter, I didn't see a detailed proposal, so I'm
not surprised people are arguing against something that probably isn't
on the table.

For starters, windmove is not a preloaded package (neither is winner,
but since this seems to be only about winmove, I guess winer needs a
separate discussion).  To have it available, you need to load it,
either explicitly or by invoking one of the commands (which are
autoloaded).  I presume that the proposal for giving windmove commands
key bindings means that the bindings will become in effect once the
package is loaded, because nothing else makes much sense to me.  Is
that indeed what's being proposed?  Does anyone have a problem with an
optional package which, when loaded, binds some keys to its commands?
That's a far cry from a naïve interpretation of "giving default key
bindings to windmove".  because a user who loads a package expresses
his/her interest in using that package, and so binding some keys for
that makes sense, and doesn't affect users who are not interested in
the package.

Now, windmove already has the windmove-default-keybindings command,
which installs key bindings for its commands.  They are not "C-x 4
<ARROW>" bindings, though.  If the proposal is to perform key bindings
when the package is loaded, and use "C-x 4 <ARROW>" for that, then we
need to make sure windmove-default-keybindings will reset the bindings
back to their current defaults, because otherwise users of windmove
will not be happy.

Any objections to the above detailed proposal?  Assuming there are no
significant objections, would someone like to take upon themselves to
submit a patch along those lines?

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On June 23, 2024 2:44:42 PM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 23 Jun 2024 10:05:13 +0000
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>>  Daniel Colascione <dancol@dancol.org>, emacs-devel@gnu.org
>> From: Alan Mackenzie <acm@muc.de>
>> 
>> Hello, Stefan and Stefan.
>> 
>> On Fri, Jun 21, 2024 at 15:39:09 -0500, Stefan Kangas wrote:
>> > Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 
>> > > A few years ago, Daniel suggested:
>> > >> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
>> > >> for people automatically, enabled by default.
>> > >
>> > > AFAICT we still don't actually provide any keybindings for the windmove
>> > > commands by default.  Did I miss a controversy about that, or did it
>> > > just fall through the cracks?
>> 
>> > FWIW, I don't remember any controversy either, so my guess is that it
>> > just fell through the cracks.
>> 
>> I would be against using C-x 4 <arrow keys> or C-x 5 <arrow-keys> for
>> windmove (or anything else) by default.  Key sequences with arrow keys
>> are too few, and too precious, to use for anything not critically
>> important.
>
>I'm not sure we all are on the same page regarding what is being
>proposed.  For that matter, I didn't see a detailed proposal, so I'm
>not surprised people are arguing against something that probably isn't
>on the table.
>
>For starters, windmove is not a preloaded package (neither is winner,
>but since this seems to be only about winmove, I guess winer needs a
>separate discussion).  To have it available, you need to load it,
>either explicitly or by invoking one of the commands (which are
>autoloaded).  I presume that the proposal for giving windmove commands
>key bindings means that the bindings will become in effect once the
>package is loaded, because nothing else makes much sense to me.  Is
>that indeed what's being proposed?  Does anyone have a problem with an
>optional package which, when loaded, binds some keys to its commands?
>That's a far cry from a naïve interpretation of "giving default key
>bindings to windmove".  because a user who loads a package expresses
>his/her interest in using that package, and so binding some keys for
>that makes sense, and doesn't affect users who are not interested in
>the package.

Why not just set up the keybindings by default and autoload the package when the bindings are invoked? That's the friction minimizing option. We don't have to change any bindings installed by the current windmove code.



>
>Now, windmove already has the windmove-default-keybindings command,
>which installs key bindings for its commands.  They are not "C-x 4
><ARROW>" bindings, though.  If the proposal is to perform key bindings
>when the package is loaded, and use "C-x 4 <ARROW>" for that, then we
>need to make sure windmove-default-keybindings will reset the bindings
>back to their current defaults, because otherwise users of windmove
>will not be happy.
>
>Any objections to the above detailed proposal?  Assuming there are no
>significant objections, would someone like to take upon themselves to
>submit a patch along those lines?

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> Date: Sun, 23 Jun 2024 14:51:11 -0400
> From: Daniel Colascione <dancol@dancol.org>
> CC: Alan Mackenzie <acm@muc.de>, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> >For starters, windmove is not a preloaded package (neither is winner,
> >but since this seems to be only about winmove, I guess winer needs a
> >separate discussion).  To have it available, you need to load it,
> >either explicitly or by invoking one of the commands (which are
> >autoloaded).  I presume that the proposal for giving windmove commands
> >key bindings means that the bindings will become in effect once the
> >package is loaded, because nothing else makes much sense to me.  Is
> >that indeed what's being proposed?  Does anyone have a problem with an
> >optional package which, when loaded, binds some keys to its commands?
> >That's a far cry from a naïve interpretation of "giving default key
> >bindings to windmove".  because a user who loads a package expresses
> >his/her interest in using that package, and so binding some keys for
> >that makes sense, and doesn't affect users who are not interested in
> >the package.
> 
> Why not just set up the keybindings by default and autoload the package when the bindings are invoked? That's the friction minimizing option. We don't have to change any bindings installed by the current windmove code.

I think this is too drastic, that's why.  The package is not loaded by
default now.  Let's first change the key bindings that become in
effect when the package is loaded, and consider doing that by default
only if the package becomes popular enough.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> Date: Sun, 23 Jun 2024 22:26:36 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: monnier@iro.umontreal.ca, acm@muc.de, stefankangas@gmail.com,
>  emacs-devel@gnu.org
> 
> > Why not just set up the keybindings by default and autoload the package when the bindings are invoked? That's the friction minimizing option. We don't have to change any bindings installed by the current windmove code.
> 
> I think this is too drastic, that's why.

Actually, even more than that: it makes little sense to me to have by
default key bindings to a package that is not preloaded.  I don't
think we have any precedent for this.  And preloading windmove is also
not justified.

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

> Actually, even more than that: it makes little sense to me to have by
> default key bindings to a package that is not preloaded.  I don't
> think we have any precedent for this.

We do have several keybindings to autoloaded functions.
The bindings in the `C-x v` keymap come to mind, for instance, but I'm
pretty sure we have many more.


        Stefan

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> > > Why not just set up the keybindings by default and autoload the
> package when the bindings are invoked? That's the friction minimizing
> option. We don't have to change any bindings installed by the current
> windmove code.
> >
> > I think this is too drastic, that's why.
> 
> Actually, even more than that: it makes little sense to me to have by
> default key bindings to a package that is not preloaded.  I don't
> think we have any precedent for this.  And preloading windmove is also
> not justified.

Exactly what I was going to say in my first reply.
But I wasn't sure you might say there _was_ such
a precedent.

Precedent or no, there's no good reason I'm aware
of for adding global key bindings just by loading
a library, especially a new one (new as part of
Emacs).

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 23/06/2024 22:26, Eli Zaretskii wrote:
>> Why not just set up the keybindings by default and autoload the package when the bindings are invoked? That's the friction minimizing option. We don't have to change any bindings installed by the current windmove code.
> I think this is too drastic, that's why.  The package is not loaded by
> default now.  Let's first change the key bindings that become in
> effect when the package is loaded, and consider doing that by default
> only if the package becomes popular enough.

The whole concept of autoloads is deferring the loading of packages 
until they are used. And it's a good one, saving on loading time and 
used memory.

We can just add bindings for those commands (which are autoloaded), no 
further changes necessary.

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> >> Why not just set up the keybindings by default and autoload the package
> when the bindings are invoked? That's the friction minimizing option. We
> don't have to change any bindings installed by the current windmove code.
> > I think this is too drastic, that's why.  The package is not loaded by
> > default now.  Let's first change the key bindings that become in
> > effect when the package is loaded, and consider doing that by default
> > only if the package becomes popular enough.
> 
> The whole concept of autoloads is deferring the loading of packages
> until they are used. And it's a good one, saving on loading time and
> used memory.
> 
> We can just add bindings for those commands (which are autoloaded), no
> further changes necessary.

Just because you want to use some feature, so
you load its package, that doesn't imply that
you also want to add a bunch of global key
bindings.

Loading is one choice/option.  Adding some key
bindings for some of its commands is another,
additional choice/option.

It's possible, but not necessary, to couple the
two.  Why do so, and especially, why do so as
soon as the library is added to Emacs?

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> > Why not just set up the keybindings by default and autoload the package
> when the bindings are invoked? That's the friction minimizing option. We
> don't have to change any bindings installed by the current windmove code.
> 
> I think this is too drastic, that's why.  The package is not loaded by
> default now.  Let's first change the key bindings that become in
> effect when the package is loaded, and consider doing that by default
> only if the package becomes popular enough.

When loaded?  Why not put them behind a minor mode
or a defcustom?  Why put key bindings in effect
just by loading the library?

The library is optional, so yes, just loading it
is one level of saying you want to use it.  But
it makes more sense for it to have a (global, I
guess) minor-mode keymap.  Whatever key bindings
we want to provide by default for this feature
can be defined in that keymap.

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

> Does anyone have a problem with an optional package which, when
> loaded, binds some keys to its commands?

I do: merely loading a file shouldn't make such changes.

I assumed the idea is rather to add keybindings maybe in `bindings.el` of
the form `[mumble] [ModifierMumble]-<left/right/up/down>` to autoloaded
commands.  So `windmove` would still not be preloaded and there'd be no
interaction with `windmove-default-keybindings`.

One proposal was to use `C-x 4` for `[mumble]`.  Not sure what should
happen with the modifiers (to choose between the various options of
selecting another window, moving the current buffer to that other
window, ...).


        Stefan

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 23/06/2024 22:52, Stefan Monnier wrote:
>> Does anyone have a problem with an optional package which, when
>> loaded, binds some keys to its commands?
> I do: merely loading a file shouldn't make such changes.

Indeed.

Re: Proposal: new default bindings for winner and windmove

[Stefan Kangas]

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

> I assumed the idea is rather to add keybindings maybe in `bindings.el` of
> the form `[mumble] [ModifierMumble]-<left/right/up/down>` to autoloaded
> commands.  So `windmove` would still not be preloaded and there'd be no
> interaction with `windmove-default-keybindings`.

That was my understanding too.

> One proposal was to use `C-x 4` for `[mumble]`.  Not sure what should
> happen with the modifiers (to choose between the various options of
> selecting another window, moving the current buffer to that other
> window, ...).

Someone (TM) should look at all that and come up with a concrete
proposal, while considering consistency with other default bindings.

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> > Does anyone have a problem with an optional package which, when
> > loaded, binds some keys to its commands?
> 
> I do: merely loading a file shouldn't make such changes.

+100.

> I assumed the idea is rather to add keybindings maybe in `bindings.el` of
> the form `[mumble] [ModifierMumble]-<left/right/up/down>` to autoloaded
> commands.  So `windmove` would still not be preloaded and there'd be no
> interaction with `windmove-default-keybindings`.
> 
> One proposal was to use `C-x 4` for `[mumble]`.  Not sure what should
> happen with the modifiers (to choose between the various options of
> selecting another window, moving the current buffer to that other
> window, ...).

Why whenever the command is autoloaded?  To me,
even that's unnecessary - overreach.  Why not
use a minor mode or a user option to add the
additional default bindings?

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dancol@dancol.org,  Alan Mackenzie <acm@muc.de>,
>   stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 23 Jun 2024 15:52:16 -0400
> 
> > Does anyone have a problem with an optional package which, when
> > loaded, binds some keys to its commands?
> 
> I do: merely loading a file shouldn't make such changes.

I didn't say "merely loading".  There's windmove-mode, for example.

> I assumed the idea is rather to add keybindings maybe in `bindings.el` of
> the form `[mumble] [ModifierMumble]-<left/right/up/down>` to autoloaded
> commands.  So `windmove` would still not be preloaded and there'd be no
> interaction with `windmove-default-keybindings`.

That makes no sense to me: to "waste" keys for an optional package.
We do this for commands for which there's no other option, like
M-. etc.  But here we do have the traditional other-window (I have it
bound to a key that is easier to type).

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 24/06/2024 05:28, Eli Zaretskii wrote:
>> From: Stefan Monnier<monnier@iro.umontreal.ca>
>> Cc:dancol@dancol.org,  Alan Mackenzie<acm@muc.de>,
>>    stefankangas@gmail.com,emacs-devel@gnu.org
>> Date: Sun, 23 Jun 2024 15:52:16 -0400
>>
>>> Does anyone have a problem with an optional package which, when
>>> loaded, binds some keys to its commands?
>> I do: merely loading a file shouldn't make such changes.
> I didn't say "merely loading".  There's windmove-mode, for example.

FWIW, windmove-mode is on by default (and autoloaded). Just without any 
key bindings set up.

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> FWIW, windmove-mode is on by default (and autoloaded). Just without
> any key bindings set up.

Because users are expected to customize windmove-*-keybindings to enable
them, no?

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> Date: Mon, 24 Jun 2024 13:41:33 +0300
> Cc: dancol@dancol.org, acm@muc.de, stefankangas@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > I didn't say "merely loading".  There's windmove-mode, for example.
> 
> FWIW, windmove-mode is on by default (and autoloaded). Just without any 
> key bindings set up.

So what exactly is requested here? change the default value of
windmove-default-keybindings?

Re: Proposal: new default bindings for winner and windmove

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> A few years ago, Daniel suggested:
>>> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
>>> for people automatically, enabled by default.
>>
>> AFAICT we still don't actually provide any keybindings for the windmove
>> commands by default.  Did I miss a controversy about that, or did it
>> just fall through the cracks?
>
> FWIW, I don't remember any controversy either, so my guess is that it
> just fell through the cracks.

I didn't manage to read the entire thread, but isn't the main issue with
C-x 4 <arrow key> that it is a relatively long key chord with a certain
travel distance on the keyboard for a quick operation?  If it is easier
to press C-x o a few times (which `repeat-mode' makes even easier), then
there is little point in adding a default binding, I feel.

I personally bind the keys directly to arrow keys, but this is not
really a practical solution for OOTB bindings.  But C-c <arrow> is not
bound by default, not are they reserved if I am reading (elisp) Key
Binding Conventions correctly.  The main issue is that winner-mode uses
C-c {left,right} when loaded, by default.  So perhaps C-c C-<arrow>,
which is easy to type and repeat?

-- 
	Philip Kaludercic on peregrine

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> I didn't manage to read the entire thread, but isn't the main issue with
> C-x 4 <arrow key> that it is a relatively long key chord with a certain
> travel distance on the keyboard for a quick operation?  If it is easier
> to press C-x o a few times (which `repeat-mode' makes even easier), then
> there is little point in adding a default binding, I feel.

I assumed the proposal was for _repeating_
keys after a prefix key: C-x 4 <down> <down>...
or even a mixture of arrow directions:
C-x 4 <down> <right> <up>, <up>...

I do this all the time - use a prefix key
followed by other keys for repeated actions,
incremental changes such as resizing a window
or frame, moving a frame around, or changing
color attributes.

E.g., a prefix key (such as `C-x 4') can be
followed by any sequence of <up>, <down>,
<left>, <right> keys, i.e., any number of
repetitions, in any order.  You move around
with all 4 arrow keys after just one hit of
the prefix key.  (You can also do so with
the mouse wheel.)

You can make repeated incremental changes to
anything.  For (in|de)crementing color
attributes I use prefix key `C-x t c', then
an increment/decrement amount, then a color
attribute key (r, g, b, h, s, v), then
up/down arrow keys or mouse wheel.  You can
change to another attribute at any time:
`C-x t c h 1 up up up v down down r up...'
         ^            ^           ^

You could use a transient map to implement
such behavior, but I didn't bother with that
(done long before that existed).
___

I've done this with DoReMi since 2004.

https://www.emacswiki.org/emacs/DoReMi

Re: [External] : Re: Proposal: new default bindings for winner and windmove

[Philip Kaludercic]

Drew Adams <drew.adams@oracle.com> writes:

>> I didn't manage to read the entire thread, but isn't the main issue with
>> C-x 4 <arrow key> that it is a relatively long key chord with a certain
>> travel distance on the keyboard for a quick operation?  If it is easier
>> to press C-x o a few times (which `repeat-mode' makes even easier), then
>> there is little point in adding a default binding, I feel.
>
> I assumed the proposal was for _repeating_
> keys after a prefix key: C-x 4 <down> <down>...
> or even a mixture of arrow directions:
> C-x 4 <down> <right> <up>, <up>...

No, then my message wouldn't make any sense.  That would just make the
key chord more complicated to type.  Switching windows is something
people do frequently and quickly.  So a "slow" binding (i.e. takes a
relatively long time to enter, especially when compare to existing
strategies) will not be that effective.

> I do this all the time - use a prefix key
> followed by other keys for repeated actions,
> incremental changes such as resizing a window
> or frame, moving a frame around, or changing
> color attributes.
>
> E.g., a prefix key (such as `C-x 4') can be
> followed by any sequence of <up>, <down>,
> <left>, <right> keys, i.e., any number of
> repetitions, in any order.  You move around
> with all 4 arrow keys after just one hit of
> the prefix key.  (You can also do so with
> the mouse wheel.)
>
> You can make repeated incremental changes to
> anything.  For (in|de)crementing color
> attributes I use prefix key `C-x t c', then
> an increment/decrement amount, then a color
> attribute key (r, g, b, h, s, v), then
> up/down arrow keys or mouse wheel.  You can
> change to another attribute at any time:
> `C-x t c h 1 up up up v down down r up...'
>          ^            ^           ^
>
> You could use a transient map to implement
> such behavior, but I didn't bother with that
> (done long before that existed).
>
> ___
>
> I've done this with DoReMi since 2004.
>
> https://www.emacswiki.org/emacs/DoReMi

-- 
	Philip Kaludercic on peregrine

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> >> I didn't manage to read the entire thread, but isn't the main issue with
> >> C-x 4 <arrow key> that it is a relatively long key chord with a certain
> >> travel distance on the keyboard for a quick operation?  If it is easier
> >> to press C-x o a few times (which `repeat-mode' makes even easier), then
> >> there is little point in adding a default binding, I feel.
> >
> > I assumed the proposal was for _repeating_
> > keys after a prefix key: C-x 4 <down> <down>...
> > or even a mixture of arrow directions:
> > C-x 4 <down> <right> <up>, <up>...
> 
> No, then my message wouldn't make any sense.

Which is why I replied.  Your msg would only
make sense if someone actually meant to say
that they would use `C-x 4 <down>' then use
that whole key sequence again to repeat the
movement, etc.

Whether it's your message that doesn't make
sense or the original proposal that doesn't
make sense, I don't know - presumably one of
the two (at least).

My point was that you can have rapid repetition
of a series of actions (even different actions)
even if you start the series using an unhandy,
non-repeatable or hard-to-repeat prefix key. 

Re: Proposal: new default bindings for winner and windmove

[Juri Linkov]

> I didn't manage to read the entire thread, but isn't the main issue with
> C-x 4 <arrow key> that it is a relatively long key chord with a certain
> travel distance on the keyboard for a quick operation?

It makes no sense to bind window navigation commands windmove-left/right
to a sequence that is longer than 'C-x o'.  However, for consistency with
other existing commands in the 'C-x 4' keymap that are used to display
a buffer in another window it makes sense to bind window directional display
commands windmove-display-left/right to 'C-x 4 left/right'.  This would be
very useful to be able to override the default choice that is always
the least recently used window that often not what you want to use.

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

Stefan Kangas [2024-06-21 15:39:09] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> A few years ago, Daniel suggested:
>>> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
>>> for people automatically, enabled by default.
>> AFAICT we still don't actually provide any keybindings for the windmove
>> commands by default.  Did I miss a controversy about that, or did it
>> just fall through the cracks?
> FWIW, I don't remember any controversy either, so my guess is that it
> just fell through the cracks.

Well, seeing the disproportionately intense fire coming from Alan and Po
Lu on such a minor proposal is a good reminder why people like to stay
away from emacs-devel.


        Stefan

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Stefan.

On Wed, Jun 26, 2024 at 11:48:22 -0400, Stefan Monnier wrote:
> Stefan Kangas [2024-06-21 15:39:09] wrote:
> > Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >> A few years ago, Daniel suggested:
> >>> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
> >>> for people automatically, enabled by default.
> >> AFAICT we still don't actually provide any keybindings for the windmove
> >> commands by default.  Did I miss a controversy about that, or did it
> >> just fall through the cracks?
> > FWIW, I don't remember any controversy either, so my guess is that it
> > just fell through the cracks.

> Well, seeing the disproportionately intense fire coming from Alan and
> Po Lu on such a minor proposal is a good reminder why people like to
> stay away from emacs-devel.

Talking about minor proposals, I got the following message in
*Async-native-compile-log*  in one of my development branches:

/home/acm/cc-mode.hg/cc-fonts.el: Error Wrong type argument: listp, #[(form) (`(cdr (backquote-process ,form))) nil]

, which clearly has to do with your "minor proposal" to introduce a new
type for interpreted functions.  I really can't be bothered at the moment
to go through all the work of tracking this down, but would be grateful
nevertheless if you would fix it.

By the way, did you get any approval for this change from the current
maintainers, or did you just go ahead and commit it anyway?  I seem to
remember you sweeping aside and ignoring my "disproportionately intense
fire" on this matter, implying it would cause nobody extra work.

The error causing it might well have found it's way into the emacs-30
branch.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Attitude (was: Proposal: new default bindings for winner and windmove)

[Eli Zaretskii]

> Date: Wed, 26 Jun 2024 20:38:35 +0000
> Cc: Stefan Kangas <stefankangas@gmail.com>,
>  Daniel Colascione <dancol@dancol.org>, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello, Stefan.

(Not really a "hello", is it?)

> Talking about minor proposals, I got the following message in
> *Async-native-compile-log*  in one of my development branches:
> 
> /home/acm/cc-mode.hg/cc-fonts.el: Error Wrong type argument: listp, #[(form) (`(cdr (backquote-process ,form))) nil]
> 
> , which clearly has to do with your "minor proposal" to introduce a new
> type for interpreted functions.  I really can't be bothered at the moment
> to go through all the work of tracking this down, but would be grateful
> nevertheless if you would fix it.
> 
> By the way, did you get any approval for this change from the current
> maintainers, or did you just go ahead and commit it anyway?  I seem to
> remember you sweeping aside and ignoring my "disproportionately intense
> fire" on this matter, implying it would cause nobody extra work.

Alan, please drop this immature attitude.  It's unbecoming.

I have no idea what change you are talking about (as you "cannot be
bothered" to point it out, evidently), and I cannot try to reproduce
it myself (since you didn't tell how) or examine the backtrace (since
you haven't posted one), but in general, this is development, and
mistakes whether silly or serious, do happen.  When mistakes do
happen, we don't castigate our fellow developers, certainly not those
with Stefan's record, for any unintended consequences of their work.
Instead, we respectfully describe the problems with all the relevant
details and discuss how to fix the problems.

IOW, this is a cooperative community effort of developing software,
and I respectfully demand that each one of us behaves accordingly.
Anyone who misbehaves on my watch will be kindly asked to stop, or
else.

I now expect you to apologize and to post the details of the problem
(as a separate bug report).

Re: Attitude (was: Proposal: new default bindings for winner and windmove)

[Alan Mackenzie]

Hello, Eli.

On Thu, Jun 27, 2024 at 08:16:14 +0300, Eli Zaretskii wrote:
> > Date: Wed, 26 Jun 2024 20:38:35 +0000
> > Cc: Stefan Kangas <stefankangas@gmail.com>,
> >  Daniel Colascione <dancol@dancol.org>, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Hello, Stefan.

> (Not really a "hello", is it?)

Er, yes it is.  I'm recognising the personality and individuality of
whoever I'm addressing, in this case Stefan.

> > Talking about minor proposals, I got the following message in
> > *Async-native-compile-log*  in one of my development branches:

> > /home/acm/cc-mode.hg/cc-fonts.el: Error Wrong type argument: listp, #[(form) (`(cdr (backquote-process ,form))) nil]

> > , which clearly has to do with your "minor proposal" to introduce a new
> > type for interpreted functions.  I really can't be bothered at the moment
> > to go through all the work of tracking this down, but would be grateful
> > nevertheless if you would fix it.

> > By the way, did you get any approval for this change from the current
> > maintainers, or did you just go ahead and commit it anyway?  I seem to
> > remember you sweeping aside and ignoring my "disproportionately intense
> > fire" on this matter, implying it would cause nobody extra work.

> Alan, please drop this immature attitude.  It's unbecoming.

Please note, I was responding to an unnecessary personal attack from
Stefan.

> I have no idea what change you are talking about (as you "cannot be
> bothered" to point it out, evidently), ....

The change was

commit f2bccae22bd47a2e7e0937b78ea06131711b935a
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Mon Mar 11 16:12:26 2024 -0400

    Use a dedicated type to represent interpreted-function values

We discussed this change, while it was still a proposal, at some length
in the emacs-devel thread starting with Subject: Distinguishing `consp`
and `functionp`; From: Stefan Monnier <monnier@iro.umontreal.ca>; Date:
Thu, 25 Jan 2024 18:15:48 -0500.  You probably remember me asking Stefan
repeatedly to justify this proposal and getting no satisfactory answers.
You even asked him yourself.  Richard pronounced emphatically against the
change, describing it as "perverse".  There was certainly no general
consensus in the list that the change would be a good thing.

Nevertheless, Stefan committed the above change on March 11.  My question
to Stefan was, did he have any approval to do so?  Let me ask you - did
you approve the change and communicate that to Stefan before his commit?
If not, did Stefan K., the only other maintainer at the time?

> .... and I cannot try to reproduce it myself (since you didn't tell
> how) or examine the backtrace (since you haven't posted one), but in
> general, this is development, and mistakes whether silly or serious, do
> happen.  When mistakes do happen, we don't castigate our fellow
> developers, certainly not those with Stefan's record, for any
> unintended consequences of their work.

In the above thread, I pointed out to Stefan that the proposed change
would necessarily cause extra work and bugs, and this is precisely what
has happened, what I described in my last post.  Stefan's response was to
mock me, without answering the point.

> Instead, we respectfully describe the problems with all the relevant
> details and discuss how to fix the problems.

The problem I encountered involved Stefan's "perverse" commit of March
11.  It contained #[(form) (`(cdr (backquote-process ,form))) nil], one
of the new interpreted forms.  Without that commit, the bug could not
have happened.  Forgive me for getting somewhat angry about this.

> IOW, this is a cooperative community effort of developing software,
> and I respectfully demand that each one of us behaves accordingly.

As I see it, the project is under the guidance and direction of you and
the other maintainers.  Richard has special privileges, as a moderate
person with an extremely high ability to discern the Right Thing, as well
as being the originator of Emacs.  In technical matters, I respect and
follow your direction, despite not always agreeing with it.  Nearly all
other contributers do the same.

But Stefan M. doesn't appear to fit this model.  He makes changes to the
code base as he sees fit, regardless of any consensus in the project, or
direction from you or the other maintainers.  Unlike you and Richard,
Stefan _doesn't_ have the ability to know the Right Thing, isn't good at
writing documentation, and isn't always as forthcoming in email exchanges
as one would expect from a senior contributor.

> Anyone who misbehaves on my watch will be kindly asked to stop, or
> else.

Stefan would appear to have special privileges in the Emacs project.
Why?

> I now expect you to apologize and to post the details of the problem
> (as a separate bug report).

Yes, I'm sorry about all this happening.  I'll open a bug report,
probably committing the current (ugly) state of my development branch
where it happened to a git branch under scratch.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Stefan Kangas]

Generally speaking, we provide an extensive set of keybindings.  These
defaults ensure that Emacs is as usable as possible out-of-the-box.

There is of course room for reasonable people to agree or disagree to
what extent this or that keybinding is useful enough to provide
out-of-the-box; this is largely a matter of taste and how you use Emacs.

However, I'm not convinced by the argument that there is some
"keybinding real estate" that we are somehow occupying by adding _any_
new defaults, since users can change keybindings relatively easily.
So there is no way around the need to consider each new proposal
individually.

Now, it is clear that there is a need for users to navigate between
windows.  The need for even more specialized commands (e.g. windmove,
ace-window) is arguably bigger today than it used to be.  Users will
routinely have huge monitors where they can have a large number of
windows visible at the same time.  What served users in 1995 will not
necessarily be enough for the needs of users today.

In my view, having considered this discussion in full, the benefits of
adding these key bindings, favored by several developers, therefore
outweigh the perceived drawbacks.

- The proposal is to add global bindings, which AFAIU means that they
  will not affect people that are binding these keys to something else
  (whether globally or in specific modes).

- People that do not like these keys do not need to use them, or they
  can unbind them, or rebind them to something else.

- The relevant windmove commands are already autoloaded.

- There is no need to deprecate anything to add these bindings.

Thus, I don't think I see any compelling reason not to go ahead with
this change.  I would propose that we now start discussing the specifics
of how to go about doing that (patches, proposed alternative solutions).

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Stefan.

On Sun, Jun 30, 2024 at 18:29:03 -0700, Stefan Kangas wrote:
> Generally speaking, we provide an extensive set of keybindings.  These
> defaults ensure that Emacs is as usable as possible out-of-the-box.

> There is of course room for reasonable people to agree or disagree to
> what extent this or that keybinding is useful enough to provide
> out-of-the-box; this is largely a matter of taste and how you use Emacs.

> However, I'm not convinced by the argument that there is some
> "keybinding real estate" that we are somehow occupying by adding _any_
> new defaults, since users can change keybindings relatively easily.
> So there is no way around the need to consider each new proposal
> individually.

The above is true, but it misses the point.  That point is that once the
Emacs maintenance team has added a _default_ binding, that can never in
the future be changed.  People will scream "backward compatibility"
until the heat death of the universe.

In that sense, "keybinding real estate" very much is a real issue - we
can only add so many default key bindings, and once added they are
difficult to change or to remove.

> Now, it is clear that there is a need for users to navigate between
> windows.  The need for even more specialized commands (e.g. windmove,
> ace-window) is arguably bigger today than it used to be.  Users will
> routinely have huge monitors where they can have a large number of
> windows visible at the same time.  What served users in 1995 will not
> necessarily be enough for the needs of users today.

This is one of these user dependant things.  For some users,
sophisticated window changing commands will be essential for using Emacs
at all, others simply won't need them, and there will be few users in
between.

> In my view, having considered this discussion in full, the benefits of
> adding these key bindings, favored by several developers, therefore
> outweigh the perceived drawbacks.

That "perceived" there is a mistake.  The drawbacks are real.  At the
very least, such usage is liable to provoke a long, withering post from
Drew Adams.  ;-)

> - The proposal is to add global bindings, which AFAIU means that they
>   will not affect people that are binding these keys to something else
>   (whether globally or in specific modes).

> - People that do not like these keys do not need to use them, or they
>   can unbind them, or rebind them to something else.

As already said, those people don't include the Emacs maintainers when
considering default key bindings.

> - The relevant windmove commands are already autoloaded.

> - There is no need to deprecate anything to add these bindings.

> Thus, I don't think I see any compelling reason not to go ahead with
> this change.  I would propose that we now start discussing the specifics
> of how to go about doing that (patches, proposed alternative solutions).

I think I would agree with the somebody else that suggested enabling
these keys by a minor mode.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Alan Mackenzie <acm@muc.de> writes:

> The above is true, but it misses the point.  That point is that once the
> Emacs maintenance team has added a _default_ binding, that can never in
> the future be changed.  People will scream "backward compatibility"
> until the heat death of the universe.
>
> In that sense, "keybinding real estate" very much is a real issue - we
> can only add so many default key bindings, and once added they are
> difficult to change or to remove.

Yes, but backwards compatibility is merely the tip of the iceberg.  New
keybindings introduce discrepancies between the habits of existing users
and the expectations of recent adopters, and, for those users who have
still to bind them, a new default keybinding that they will be reluctant
to override.  If only because they regard our work and our judgement
with respect, which extends to the keybindings we select as well.  All
the more reason _NOT_ to adopt a collection of bindings in a keymap to
which they are adventitious, and for a package objectively less popular
than ffap, which does deserve a place in the said keymap, upon a
proposal by their only user.

>> In my view, having considered this discussion in full, the benefits of
>> adding these key bindings, favored by several developers, therefore
>> outweigh the perceived drawbacks.

Used by one.  Favored by several who probably have not formed strong
opinions in either direction, as did the ingenuous respondents to the
Time magazine poll mentioned here:

  https://www.commentary.org/articles/robert-myers/the-study-of-man-opinion-polls-and-public-policy/

>> - The proposal is to add global bindings, which AFAIU means that they
>>   will not affect people that are binding these keys to something else
>>   (whether globally or in specific modes).

You state that it does not, but this has been disputed three times over
in this thread alone (and again in the first paragraph), no one having
so much as acknowledged the disagreement, let alone pretended seriously
to offer a rebuttal.

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 01/07/2024 13:47, Po Lu wrote:

>>> In my view, having considered this discussion in full, the benefits of
>>> adding these key bindings, favored by several developers, therefore
>>> outweigh the perceived drawbacks.
> 
> Used by one.  Favored by several who probably have not formed strong
> opinions in either direction, as did the ingenuous respondents to the
> Time magazine poll mentioned here:
> 
>    https://www.commentary.org/articles/robert-myers/the-study-of-man-opinion-polls-and-public-policy/

Your stats are off.

>>> - The proposal is to add global bindings, which AFAIU means that they
>>>    will not affect people that are binding these keys to something else
>>>    (whether globally or in specific modes).
> 
> You state that it does not, but this has been disputed three times over
> in this thread alone (and again in the first paragraph), no one having
> so much as acknowledged the disagreement, let alone pretended seriously
> to offer a rebuttal.

No it wasn't.

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Your stats are off.

Any evidence to back this claim?  Have you, perhaps, developed strong
opinions on the subject, more worthy of consideration than a
questionable identification of persons as problems?  Is it really wise
to steer this discussion further off course towards impugning persons,
and in short order, specific persons among us?

> No it wasn't.

I'll give one example of what is _NOT_ an acknowledgement:

> ...I haven't seen why in this case binding these keys is a
> particularly bad idea. The original argument is that providing these
> bindings would somehow override user customization. They
> won't. There's no deprivation of user customization, so the "scarcity"
> of arrow key bindings is irrelevant. Now the objection is over
> "clutter"? Does an arrow key binding somehow create more clutter than
> some other binding? There's nothing special about these bindings.

"I haven't heard you."  "What you said is false."  "You're WRONG."
"You're moving the goalposts."  "There is NOTHING of substance to what
you have said."

And one more:

> Again, you're making a general argument against adding any new
> bindings whatsoever. I don't think that's a good thing. The very same
> argument would have applied to the vc and project default bindings.

"You're arguing TOO GENERALLY, i.e. WRONG!"  "Therefore, I think you're
wrong."  [Totally immaterial and accomplished facts which may or may not
be reexamined in a different light with the benefit of hindsight.]

And, the grand finale, the snub to end all snubs:

>> This is just one, and by far not the most compelling, of many
>> objections to introducing new default keybindings, but one of which a
>> recent example comes to mind: C-x x u has for many years been bound
>> in my sessions to a command that deletes a buffer's undo list,
>> usually in the interests of security.  The consequences of a
>> stranger's unsuspectingly typing the same to invoke rename-uniquely
>> might easily have been catastrophic.
>
> This attitude is why Doom Emacs exists. A live software project is one
> that changes. A dead one prioritizes stasis over user experience.
>
> Nothing we're talking about here will disturb your custom
> keybindings. Your experience will work just as it did before.

In what sense does this even purport to address the scenario I
illustrated in such particular terms?

Now, then, consider:

  https://lists.gnu.org/archive/html/emacs-devel/2024-06/msg00926.html

How many of those issues which I raised have since been addressed?  If
they have, where are these answers, and what is their relation to my
questions?

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 01/07/2024 16:20, Po Lu wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>> Your stats are off.
> 
> Any evidence to back this claim?

Yes: all popular "Emacs distributions" like Doom, or Prelude, or earlier 
ones, have all included windmove in their default config.

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Yes: all popular "Emacs distributions" like Doom, or Prelude, or
> earlier ones, have all included windmove in their default config.

That's evidence of a "strong opinion"'s being formed in this thread?

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

Hi Alan,

On 01/07/2024 13:07, Alan Mackenzie wrote:
> The above is true, but it misses the point.  That point is that once the
> Emacs maintenance team has added a_default_  binding, that can never in
> the future be changed.  People will scream "backward compatibility"
> until the heat death of the universe.

People screaming "backward compatibility" for each and every reason can 
indeed be a problem.

We should be able to change default key bindings more freely than we do now.

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> People screaming "backward compatibility" for each and every reason
  ^^^^^^
> can indeed be a problem.
      ^^^^^^^^^^^^^^^^^^^

Is this what it comes down to?  That certain people, by implication,
Emacs users, are potentially problems?  I would be exceedingly careful
where I take this discussion from hence.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Alan Mackenzie <acm@muc.de>,  Stefan Kangas <stefankangas@gmail.com>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,  Daniel Colascione
>  <dancol@dancol.org>,  emacs-devel@gnu.org
> Date: Mon, 01 Jul 2024 21:28:11 +0800
> 
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
> > People screaming "backward compatibility" for each and every reason
>   ^^^^^^
> > can indeed be a problem.
>       ^^^^^^^^^^^^^^^^^^^
> 
> Is this what it comes down to?  That certain people, by implication,
> Emacs users, are potentially problems?  I would be exceedingly careful
> where I take this discussion from hence.

I really don't understand why you-all keep reiterating the same
arguments, on and on.  The real decision about this will not be
affected by repeating old arguments, then posting counter-arguments,
etc. etc.  Just let it go.  The Emacs maintainers are fully capable of
making the decision without hearing these repetitions.  In fact, I'm
pretty sure we've already decided.

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 01/07/2024 16:28, Po Lu wrote:
> Dmitry Gutov<dmitry@gutov.dev>  writes:
> 
>> People screaming "backward compatibility" for each and every reason
>    ^^^^^^
>> can indeed be a problem.
>        ^^^^^^^^^^^^^^^^^^^
> 
> Is this what it comes down to?  That certain people, by implication,
> Emacs users, are potentially problems?

"People screaming" is a process.

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Dmitry.

On Mon, Jul 01, 2024 at 14:25:51 +0300, Dmitry Gutov wrote:
> Hi Alan,

> On 01/07/2024 13:07, Alan Mackenzie wrote:
> > The above is true, but it misses the point.  That point is that once the
> > Emacs maintenance team has added a_default_  binding, that can never in
> > the future be changed.  People will scream "backward compatibility"
> > until the heat death of the universe.

> People screaming "backward compatibility" for each and every reason can 
> indeed be a problem.

Yes, but it's a difficult problem.  I would be screaming if somebody
suggested removing the bindings C-o or C-M-o, for example.  I use these
all the time.  But if I were the only user of them, it would be
difficult to argue for their retention in the default key map.

On the other hand, C-x w h (highlight-regexp) already has a "more
modern" binding M-s h r, so although I wouldn't be enthused about the
removal of C-x w h, I wouldn't object to it either.

> We should be able to change default key bindings more freely than we do now.

Yes, but...  Every time we do this, we're upsetting _sombody_'s work
flow.  I don't see any way of getting this increased freedom to change.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

[Re-sending: accidentally sent narrow reply]

Alan Mackenzie <acm@muc.de> writes:
> Hello, Dmitry.
>
> On Mon, Jul 01, 2024 at 14:25:51 +0300, Dmitry Gutov wrote:
>> Hi Alan,
>
>> On 01/07/2024 13:07, Alan Mackenzie wrote:
>> > The above is true, but it misses the point.  That point is that once the
>> > Emacs maintenance team has added a_default_  binding, that can never in
>> > the future be changed.  People will scream "backward compatibility"
>> > until the heat death of the universe.
>
>> People screaming "backward compatibility" for each and every reason can 
>> indeed be a problem.
>
> Yes, but it's a difficult problem.  I would be screaming if somebody
> suggested removing the bindings C-o or C-M-o, for example.  I use these
> all the time.  But if I were the only user of them, it would be
> difficult to argue for their retention in the default key map.

I still think we need to find a better binding for C-o, FWIW.
I recognize I'm in the minority on this position though, but still, I
think I've used C-o maybe once or twice ever.

What do you use it for?

> On the other hand, C-x w h (highlight-regexp) already has a "more
> modern" binding M-s h r, so although I wouldn't be enthused about the
> removal of C-x w h, I wouldn't object to it either.

What do you think of my previous keybindings-editions proposal?

>> We should be able to change default key bindings more freely than we do now.
>
> Yes, but...  Every time we do this, we're upsetting _sombody_'s work
> flow.  I don't see any way of getting this increased freedom to change.

I love how https://xkcd.com/1172/ is about us.

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Daniel Colascione <dancol@dancol.org> writes:

> I still think we need to find a better binding for C-o, FWIW.
> I recognize I'm in the minority on this position though, but still, I
> think I've used C-o maybe once or twice ever.
>
> What do you use it for?

What do you expect?  Opening a new line?  Every Emacs-like editor of the
past several decades have bound such a command to C-o, and proposing to
change it now is plainly absurd.  Even GNOME does, if "Emacs shortcuts"
are enabled, to the best of my knowledge.

> I love how https://xkcd.com/1172/ is about us.

It means we're doing our job.

C-o (was: Proposal: new default bindings for winner and windmove)

[Stefan Monnier]

>> I still think we need to find a better binding for C-o, FWIW.
[...]
>> What do you use it for?

I'm also curious to know how people use `C-o`, which I never ever use.

> What do you expect?  Opening a new line?

Not sure what answer Daniel was looking for, but for me at least the
question is about the "context" where you use `C-o`.  E.g. I can see
someone doing

    C-o foo bar

but I don't see the benefit compared to

    foo bar RET

It probably comes down to habit, but I'm hoping there's more to it
than that.


        Stefan

Re: C-o

[Po Lu]

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

> Not sure what answer Daniel was looking for, but for me at least the
> question is about the "context" where you use `C-o`.  E.g. I can see
> someone doing
>
>     C-o foo bar
>
> but I don't see the benefit compared to
>
>     foo bar RET
>
> It probably comes down to habit, but I'm hoping there's more to it
> than that.

The advantage is that it is possible to continue typing on the current
line after opening another, as may be desired when entering parameters
to functions, and in similar contexts?  It's not strictly proper to
treat of the two operations in terms of their relative advantages,
moreover, they are simply fundamentally incomparable.

Consider the scenario of inserting a parameter between these two:

  x_y_z (a_voluminous_identifier (), composed_of_polysyllables ());

At the cost of two additional keystrokes (C-f and TAB), neighboring
parameters will not move as the new parameter is input.  This example
was just taken from the lossage of an actual editing session.

Re: C-o

[Gerd Möllmann]

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

>>> I still think we need to find a better binding for C-o, FWIW.
> [...]
>>> What do you use it for?
>
> I'm also curious to know how people use `C-o`, which I never ever use.

I'm using it relatively often, but almost exclusively in C-a C-o.

Re: C-o

[Visuwesh]

[திங்கள் ஜூலை 01, 2024] Stefan Monnier wrote:

>>> I still think we need to find a better binding for C-o, FWIW.
> [...]
>>> What do you use it for?
>
> I'm also curious to know how people use `C-o`, which I never ever use.

I primarily use it when I'm rewriting a sentence.  I like to keep the
old sentence around to compare it with the rewritten one but it is
distracting to have them in the same paragraph so I move to beginning of
the sentence if required and type C-o.  I could type RET but that does
not preserve the point.  Finally, I join the lines together and kill the
old sentence (I have M-j behave like M-- M-^).  Note how I never have to
move the point except initially.
[ I should say that I find it more natural to think and manipulate text
  vertically downwards rather than vertically upwards like Emacs
  commands do.  Which is why I find it hard to wrap my brain around
  transpose-lines and delete-indentation.  It may be due to my using vi
  before Emacs.  ]

Like Po Lu says, it also comes in handy when you're typing in function
parameters too.

I started using C-o after enabling hard newlines though.  Although RET
still inserts hard newlines, my brain still thinks of RET as inserting
soft newlines so I started to use C-o.  Then I found cases for it
outside of the hard-soft newline thingy.

>> What do you expect?  Opening a new line?
>
> Not sure what answer Daniel was looking for, but for me at least the
> question is about the "context" where you use `C-o`.

I hope I provided some context.  Preservation of the point is very
handy.  I think I would enjoy C-M-o more in prog-mode but it is a lot
more cumbersome to type.  Perhaps, I should try rebinding C-o to C-M-o.

Re: C-o

[Dmitry Gutov]

On 02/07/2024 06:26, Stefan Monnier wrote:
>>> I still think we need to find a better binding for C-o, FWIW.
> [...]
>>> What do you use it for?
> I'm also curious to know how people use `C-o`, which I never ever use.
> 
>> What do you expect?  Opening a new line?
> Not sure what answer Daniel was looking for, but for me at least the
> question is about the "context" where you use `C-o`.  E.g. I can see
> someone doing
> 
>      C-o foo bar
> 
> but I don't see the benefit compared to
> 
>      foo bar RET

A lot of times I used it due to the expectation that RET will reindent 
the current line and will do so incorrectly (which happens).

Looks like C-j is a possible alternative, but somehow that didn't grow 
into the muscle memory, and in some buffers it does something different 
(e.g. inside *scratch*).

Re: C-o

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> A lot of times I used it due to the expectation that RET will reindent
> the current line and will do so incorrectly (which happens).
>
> Looks like C-j is a possible alternative, but somehow that didn't grow
> into the muscle memory, and in some buffers it does something
> different (e.g. inside *scratch*).

For a less embellished alternative to C-j or RET, C-q C-j is probably
the better option.

Re: C-o

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  Daniel Colascione
>  <dancol@dancol.org>,  Alan Mackenzie <acm@muc.de>,  Stefan Kangas
>  <stefankangas@gmail.com>,  emacs-devel@gnu.org
> Date: Tue, 02 Jul 2024 21:06:09 +0800
> 
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
> > A lot of times I used it due to the expectation that RET will reindent
> > the current line and will do so incorrectly (which happens).
> >
> > Looks like C-j is a possible alternative, but somehow that didn't grow
> > into the muscle memory, and in some buffers it does something
> > different (e.g. inside *scratch*).
> 
> For a less embellished alternative to C-j or RET, C-q C-j is probably
> the better option.

Only if you are young enough to not have C-j burned into your muscle
memory as what RET does in most places in Emacs nowadays.

Old Sun keyboards had an LFD key, and Emacs used it a lot in old
versions.  Which made C-j anything but a simple newline key.

And having to quote a key is a sign of a key-binding bug in my book.

Re: C-o

[Alfred M. Szmidt]

   > > A lot of times I used it due to the expectation that RET will reindent
   > > the current line and will do so incorrectly (which happens).
   > >
   > > Looks like C-j is a possible alternative, but somehow that didn't grow
   > > into the muscle memory, and in some buffers it does something
   > > different (e.g. inside *scratch*).
   > 
   > For a less embellished alternative to C-j or RET, C-q C-j is probably
   > the better option.

   Only if you are young enough to not have C-j burned into your muscle
   memory as what RET does in most places in Emacs nowadays.

There are also a few where there is quite a big difference, e.g., in
any "REPL" like setting where C-j and RET have very different
behaviour.  Say, a shell buffer... RET behaviour depends on the mode
more often than not, while C-o and C-j generally don't.	

   Old Sun keyboards had an LFD key, and Emacs used it a lot in old
   versions.  Which made C-j anything but a simple newline key.

   And having to quote a key is a sign of a key-binding bug in my book.

Re: C-o

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Only if you are young enough to not have C-j burned into your muscle
> memory as what RET does in most places in Emacs nowadays.
>
> Old Sun keyboards had an LFD key, and Emacs used it a lot in old
> versions.  Which made C-j anything but a simple newline key.

I think by "less embellished C-j or RET", I meant a command that inserts
a line feed character, which remains the same whether entered as Ctrl+j
or XK_Linefeed on the keyboard.

> And having to quote a key is a sign of a key-binding bug in my book.

What's the alternative?

Re: C-o

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: dmitry@gutov.dev,  monnier@iro.umontreal.ca,  dancol@dancol.org,
>   acm@muc.de,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 03 Jul 2024 17:24:10 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> I think by "less embellished C-j or RET", I meant a command that inserts
> a line feed character, which remains the same whether entered as Ctrl+j
> or XK_Linefeed on the keyboard.
> 
> > And having to quote a key is a sign of a key-binding bug in my book.
> 
> What's the alternative?

C-o, of course, what else?

Re: C-o

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> C-o, of course, what else?

To produce the same effect, one must also type "C-n", which still
amounts to two keystrokes.  But I see your point.

Re: C-o

[T.V Raman]

A long time ago I started using C-o as my outline prefix key and put
open-line on C-o o Yes, Emacs needs more modifiers! I also now use xcape
to turn the Windows modifier keys into C-x and C-c -- helps the strain
on my  hands, C-x especially causes stress, even if you use caps-lock as
CTRL.

-- 

Re: C-o

[Alfred M. Szmidt]

   A long time ago I started using C-o as my outline prefix key and put
   open-line on C-o o Yes, Emacs needs more modifiers! 

It is not Emacs that needs more bucky keys, it has Control, Meta,
Super, and Hyper .. on top of Shift.  The issue is that keyboards make
anything beyond Meta impossible to type.  What would be nice is
dedicated keys, C-x 4 and C-x 5 could have a dedicated <window> and
<frame> key (they aren't modifiers ..).

   I also now use xcape to turn the Windows modifier keys into C-x and
   C-c -- helps the strain on my hands, C-x especially causes stress,
   even if you use caps-lock as CTRL.

I have Control mapped to the key beside the Space bar, as intended.
Control should be used for the most frequent things one does in Emacs,
Meta for things that are slightly larger and less common but common
enough.  C-M-.. expanding the scope of an action, etc.

That is at least how Emacs was intended to be ..

Re: C-o

[Michael Heerdegen via Emacs development discussions.]

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

> I'm also curious to know how people use `C-o`, which I never ever use.

I can only add something trivial: contrary to RET, C-o doesn't move
point, which is sometimes what I want, and sometimes not.

Michael.

Re: C-o (was: Proposal: new default bindings for winner and windmove)

[Stefan Kangas]

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

> Not sure what answer Daniel was looking for, but for me at least the
> question is about the "context" where you use `C-o`.  E.g. I can see
> someone doing
>
>     C-o foo bar
>
> but I don't see the benefit compared to
>
>     foo bar RET
>
> It probably comes down to habit, but I'm hoping there's more to it
> than that.

When I want to insert a new line above the current one, the easiest way
is two keys:

    C-a C-o

Without C-o, I'd need to use three keys:

    C-a RET <up>

I also use it to split lines and keep point at the current location.
For example, when in the middle of some line, I press

    C-o

Instead of

    RET <left>

It's minor, admittedly, but I'm so used to it that I'd miss it if I
didn't have it.  Vim has similar commands on o and O, IIRC.

Re: C-o

[Jeremy Bryant]

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

>>> I still think we need to find a better binding for C-o, FWIW.
> [...]
>>> What do you use it for?
>
> I'm also curious to know how people use `C-o`, which I never ever use.
>
>> What do you expect?  Opening a new line?
>
> Not sure what answer Daniel was looking for, but for me at least the
> question is about the "context" where you use `C-o`.  E.g. I can see
> someone doing
>
>     C-o foo bar
>
> but I don't see the benefit compared to
>
>     foo bar RET
>
> It probably comes down to habit, but I'm hoping there's more to it
> than that.
>
>
>         Stefan

C-o helps with readability (esp. with code rather than text) if you want
to insert a blank line before typing.

Furthermore the above 2 example are not quite interchangeable as
foo bar RET
moves you to the second line, which you may not always want, compared to
C-o foo bar


C-o open-line, appears to be an example of a pragmatic editing command
which is present in Emacs but not generally in other text editors.  Its
presence could be the result of accumulated wisdom.
Different typists use different commands.

Re: C-o (was: Proposal: new default bindings for winner and windmove)

[Per Starbäck]

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

>
>  I can see
> someone doing
>
>     C-o foo bar
>
> but I don't see the benefit compared to
>
>     foo bar RET
>
> It probably comes down to habit, but I'm hoping there's more to it
> than that.
>

I have realized I want to add more text somewhere in the text:
----------------------------------------------------------------------
This is the beginning of the text before the insertion. Here is the
end of the text, after the insertion.
----------------------------------------------------------------------
Point is on "H" in "Here". Before typing the new text I do C-o to get the
continuation out of the way while typing. I wouldn't do that if I'm just
adding something short, but if I'm adding a longer text I would.
In programming I would also do that if adding something longer or something
complicated. It feels better to be at the end of the line when adding text
than to push text in front of you, which can look a bit disturbing,
especially if it is long enough to be broken over to the next line.

I guess this is mostly by habit, but I see at least some advantages of
entering text at the end of the line. Then it's easier to C-e back to point
of entry if I go back to revise something just written, and I can use the
special case of C-t  for quick fixing. Also pushing text in front of me
will be a problem for ispell-word and other commands that look up the
current word. I could make sure to position myself before a space to avoid
that problem, but that would be an extra step to make where just C-o is
simpler.

[-- Attachment #2: Type: text/html, Size: 1912 bytes --]

Re: C-o

[Howard Melman]

Per Starbäck <per.starback@gmail.com> writes:

> I have realized I want to add more text somewhere in the text:
> ----------------------------------------------------------------------
> This is the beginning of the text before the insertion. Here is the
> end of the text, after the insertion.
> ----------------------------------------------------------------------
> Point is on "H" in "Here". Before typing the new text I do
> C-o to get the continuation out of the way while typing.
> I wouldn't do that if I'm just adding something short, but
> if I'm adding a longer text I would.  In programming I
> would also do that if adding something longer or something
> complicated. It feels better to be at the end of the line
> when adding text than to push text in front of you, which
> can look a bit disturbing, especially if it is long enough
> to be broken over to the next line.

I do this too.  I write prose with soft newlines in
visual-line mode, usually in markdown-mode which can have
some performance problems with font-locking in larger
buffers.  If I'm inserting text in the middle of a paragraph
I'll use C-o to make the paragraph smaller first which can
alleviate the performance issue.  I'll then rejoin the
paragraph if I added text or delete the following paragraph
if I've rewritten it and convinced myself the new text is
better. 

I also commonly use C-x C-o (delete-blank-lines) so having
line changing commands on C-o seems consistent to me.

Oddly I never use join-line M-^ instead making use of C-k
and C-d and M-SPC for such work.

-- 

Howard

Re: C-o

[Yuri Khan]

On Wed, 3 Jul 2024 at 22:25, Howard Melman <hmelman@gmail.com> wrote:

> I write prose with soft newlines in
> visual-line mode, usually in markdown-mode which can have
> some performance problems with font-locking in larger
> buffers.  If I'm inserting text in the middle of a paragraph
> I'll use C-o to make the paragraph smaller first which can
> alleviate the performance issue.

Since markdown uses blank lines to separate paragraphs,
you could use hard newlines within paragraphs
and place them at strategic points
such as ends of sentences and phrases.

This would probably solve performance issues you mention
and give you more useful diffs.
Your text insertions would also, with high probability,
start on line boundaries.

This is called “semantic line breaks”[1].
This message is formatted this way.

[1]: https://sembr.org/

Re: C-o

[Howard Melman]

> On Jul 3, 2024, at 12:24 PM, Yuri Khan <yuri.v.khan@gmail.com> wrote:
> 
> Since markdown uses blank lines to separate paragraphs,
> you could use hard newlines within paragraphs
> and place them at strategic points
> such as ends of sentences and phrases.
> 
> This would probably solve performance issues you mention
> and give you more useful diffs.
> Your text insertions would also, with high probability,
> start on line boundaries.

I'm on a mac, using soft linebreaks in emacs means
I can cut & paste to other apps with expected results.

Howard

Re: C-o

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

  > > This would probably solve performance issues you mention
  > > and give you more useful diffs.
  > > Your text insertions would also, with high probability,
  > > start on line boundaries.

  > I'm on a mac, using soft linebreaks in emacs means
  > I can cut & paste to other apps with expected results.

I wonder about two questions:

* What happens when other people edit or look at your code running
Emacs on GNU/Linux?

* What happens when other people edit or look at your code using
other tools, not involving Emacs?

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

Re: C-o

[Howard Melman]

> On Jul 5, 2024, at 12:14 AM, Richard Stallman <rms@gnu.org> wrote:
> 
>>> This would probably solve performance issues you mention
>>> and give you more useful diffs.
>>> Your text insertions would also, with high probability,
>>> start on line boundaries.
> 
>> I'm on a mac, using soft linebreaks in emacs means
>> I can cut & paste to other apps with expected results.
> 
> I wonder about two questions:
> 
> * What happens when other people edit or look at your code running
> Emacs on GNU/Linux?
> 
> * What happens when other people edit or look at your code using
> other tools, not involving Emacs?

In my original message I mentioned I was talking about prose
which I typically edit in emacs in markdown-mode, not code.

My code uses newlines same as on other platforms.

My prose typically has no newlines within a paragraph.
IME, most apps will wrap that the way visual-line-mode will
in emacs.  This message I wrote in macOS Mail.app and
included (hard) newlines.

Howard

Re: C-o

[Bob Rogers]

   From: Howard Melman <hmelman@gmail.com>
   Date: Wed, 03 Jul 2024 08:48:35 -0400

   Per Starbäck <per.starback@gmail.com> writes:

   > I have realized I want to add more text somewhere in the text:
   > ----------------------------------------------------------------------
   > This is the beginning of the text before the insertion. Here is the
   > end of the text, after the insertion.
   > ----------------------------------------------------------------------
   > Point is on "H" in "Here". Before typing the new text I do
   > C-o to get the continuation out of the way while typing . . .

   I do this too . . .

Likewise; Per might as well have been reading my mind, his practices
there and the rationale for them are so close to mine.  Admittedly, my
use of C-o may be a holdover from the days of slow terminals, but
"pushing text in front of me" still feels somewhat claustrophobic even
when I don't have to wait for line wrapping.

   I also commonly use C-x C-o (delete-blank-lines) so having
   line changing commands on C-o seems consistent to me.

   Oddly I never use join-line M-^ instead making use of C-k
   and C-d and M-SPC for such work.

   -- 

   Howard

Curiously, I'm the other way around, using M-^ but not C-x C-o.  I
suppose one can fit only so much Emacs into one's head.

					-- Bob Rogers
					   http://www.rgrjr.com/

Re: Proposal: new default bindings for winner and windmove

[Philip Kaludercic]

Daniel Colascione <dancol@dancol.org> writes:

> [Re-sending: accidentally sent narrow reply]
>
> Alan Mackenzie <acm@muc.de> writes:
>> Hello, Dmitry.
>>
>> On Mon, Jul 01, 2024 at 14:25:51 +0300, Dmitry Gutov wrote:
>>> Hi Alan,
>>
>>> On 01/07/2024 13:07, Alan Mackenzie wrote:
>>> > The above is true, but it misses the point.  That point is that once the
>>> > Emacs maintenance team has added a_default_  binding, that can never in
>>> > the future be changed.  People will scream "backward compatibility"
>>> > until the heat death of the universe.
>>
>>> People screaming "backward compatibility" for each and every reason can 
>>> indeed be a problem.
>>
>> Yes, but it's a difficult problem.  I would be screaming if somebody
>> suggested removing the bindings C-o or C-M-o, for example.  I use these
>> all the time.  But if I were the only user of them, it would be
>> difficult to argue for their retention in the default key map.
>
> I still think we need to find a better binding for C-o, FWIW.
> I recognize I'm in the minority on this position though, but still, I
> think I've used C-o maybe once or twice ever.
>
> What do you use it for?

My hands rewrite RET C-b to a C-o (especially when repeated).  I know I
use it frequently, but I cannot think of a nice example.  That is part
of the issue: These key bindings constitute a mental language of a lot
of Emacs users.  Removing, rebinding, changing these is disruptive, just
as it would be disruptive to wear mittens all day long or not being
allowed to use words that end in "u".  When writing and editing, I don't
directly think in keybindings, but in text-manipulations, as I supposed
others do too.  On a less conscious level my fingers figure out the
keybindings for everyday tasks, just as one doesn't think about moving
every single finger when lifting up an object.  Having to wake up from
this automatism, due to a missing binding is disproportional annoying.

(I am reminded of the ConTeXt vs LaTeX story, where ConTeXt might have
been cleaner, but LaTeX preserved backwards compatibility.  In the long
run, this turned out to be an advantage for LaTeX, which despite its
kluges, ended up being more reliable, especially when trying to
re-typeset and old document.  In the same sense, Emacs has these or
those peculiar, arbitrary but fixed choices that make it a reliable
foundation, for whatever changes happen around it (to operating systems,
window managers, desktop environments, ...).)

Also, in the case of C-o, there is a family of mnemonically related
bindings, such as C-x C-o and C-c C-o and C-c M-o in comint buffers.

>> On the other hand, C-x w h (highlight-regexp) already has a "more
>> modern" binding M-s h r, so although I wouldn't be enthused about the
>> removal of C-x w h, I wouldn't object to it either.
>
> What do you think of my previous keybindings-editions proposal?
>
>>> We should be able to change default key bindings more freely than we do now.
>>
>> Yes, but...  Every time we do this, we're upsetting _sombody_'s work
>> flow.  I don't see any way of getting this increased freedom to change.
>
> I love how https://xkcd.com/1172/ is about us.
>
>
>
>

-- 
	Philip Kaludercic on peregrine

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Daniel Colascione <dancol@dancol.org>
> Cc: Dmitry Gutov <dmitry@gutov.dev>,  Stefan Kangas
>  <stefankangas@gmail.com>,  Stefan Monnier <monnier@iro.umontreal.ca>,
>  emacs-devel@gnu.org
> Date: Mon, 01 Jul 2024 18:07:03 -0400
> 
> I still think we need to find a better binding for C-o, FWIW.
> I recognize I'm in the minority on this position though, but still, I
> think I've used C-o maybe once or twice ever.

I use it all the time.

> What do you use it for?

Open a new line, no questions asked and no bells and whistles that RET
brings with it (which can sometimes drive me insane).

> I love how https://xkcd.com/1172/ is about us.

It's about everybody.

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

Hi Alan,

On 02/07/2024 00:24, Alan Mackenzie wrote:

>> People screaming "backward compatibility" for each and every reason can
>> indeed be a problem.
> 
> Yes, but it's a difficult problem.  I would be screaming if somebody
> suggested removing the bindings C-o or C-M-o, for example.  I use these
> all the time.  But if I were the only user of them, it would be
> difficult to argue for their retention in the default key map.

An addition of a binding should pose less immediate danger than a 
removal of one, shouldn't it?

And okay, we might want to take care in adding bindings because later it 
would be hard to remove. But we are unlikely to be in 100% agreement for 
every such addition. It seems impossible to make every new addition 
"ideal" in that sense.

> On the other hand, C-x w h (highlight-regexp) already has a "more
> modern" binding M-s h r, so although I wouldn't be enthused about the
> removal of C-x w h, I wouldn't object to it either.

That's how I tend to think about this as well.

>> We should be able to change default key bindings more freely than we do now.
> 
> Yes, but...  Every time we do this, we're upsetting _sombody_'s work
> flow.  I don't see any way of getting this increased freedom to change.

Somebody mentioned telemetry in this thread earlier, apparently it was 
not received well. But some consistent way of polling users might help. 
Sometime later when we establish one.

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> > Yes, but...  Every time we do this, we're upsetting _sombody_'s work
> > flow.  I don't see any way of getting this increased freedom to change.
> 
> Somebody mentioned telemetry in this thread earlier, apparently it was
> not received well. But some consistent way of polling users might help.
> Sometime later when we establish one.

As I replied to Alan, adding another default key
binding doesn't necessarily upset anyone's workflow
(though it typically does hit someone somewhere).

What it does always do is reduce the domain of
keys that aren't bound by default.  And that's
more serious than just messing with a few users'
existing workflows.

Shouldn't be done lightly.  And even accurate
telemetry (or telepathy!) can help with that.
Maybe it would help avoid treading on more toes,
but it still removes a key from the non-default
free list.

Re: [External] : Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 02/07/2024 04:51, Drew Adams wrote:
>>> Yes, but...  Every time we do this, we're upsetting_sombody_'s work
>>> flow.  I don't see any way of getting this increased freedom to change.
>> Somebody mentioned telemetry in this thread earlier, apparently it was
>> not received well. But some consistent way of polling users might help.
>> Sometime later when we establish one.
> As I replied to Alan, adding another default key
> binding doesn't necessarily upset anyone's workflow
> (though it typically does hit someone somewhere).

I think he's asking a valid question I've had to ponder on multiple 
occasions myself: when the backward compatibility promise is so strong 
that we never end up deleting anything (roughly speaking), we have to 
think real hard when adding any new thing.

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> >>> Yes, but...  Every time we do this, we're upsetting_sombody_'s work
> >>> flow.  I don't see any way of getting this increased freedom to
> >>> change.
> >> Somebody mentioned telemetry in this thread earlier, apparently it was
> >> not received well. But some consistent way of polling users might help.
> >> Sometime later when we establish one.
> >
> > As I replied to Alan, adding another default key
> > binding doesn't necessarily upset anyone's workflow
> > (though it typically does hit someone somewhere).
> 
> I think he's asking a valid question I've had to ponder on multiple
> occasions myself: when the backward compatibility promise is so strong
> that we never end up deleting anything (roughly speaking), we have to
> think real hard when adding any new thing.

I don't have anything special to say about that
here.  I will say that my point here is not at
all about backward compatibility.

That may be an additional consideration, but
it's different from the aim to be conservative
about allocation of limited (and especially,
now rare) resources.

Re: Proposal: new default bindings for winner and windmove

[Stefan Kangas]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Somebody mentioned telemetry in this thread earlier, apparently it was
> not received well. But some consistent way of polling users might help.
> Sometime later when we establish one.

Telemetry is actually an excellent idea, iff it is opt-in and reasonably
anonymized (e.g. by using randomized identifiers for Emacs installations
rather than users, and optionally also Tor).

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> > We should be able to change default key bindings more freely than we do
> now.
> 
> Yes, but...  Every time we do this, we're
> upsetting _sombody_'s work flow.

No.  Sacrificing a free key to a new default
binding isn't necessarily about upsetting
anyone's workflow.  (But yes, that's likely.) 

It IS necessarily about expanding the frontier
of DefaultEmacsLand.  The remaining unclaimed
territory is a scarce resource, now more than
ever.  That aquifer's nearly drained already.

Whether some key binding is already used by
someone, or by many, is a different problem.

Emacs's grabbing more territory for default
bindings is a bigger problem than exercising
its Eminent Domain over this or that person's
binding. 

Binding `C-x 4 <arrow key>' doesn't interfere
with my workflow, but I still spoke up against
sacrificing `C-x 4' with <up>, <down>, <left>,
<right>.

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Daniel.

On Mon, Jul 01, 2024 at 18:05:42 -0400, Daniel Colascione wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > On Mon, Jul 01, 2024 at 14:25:51 +0300, Dmitry Gutov wrote:
> >> Hi Alan,

> >> On 01/07/2024 13:07, Alan Mackenzie wrote:
> >> > The above is true, but it misses the point.  That point is that once the
> >> > Emacs maintenance team has added a_default_  binding, that can never in
> >> > the future be changed.  People will scream "backward compatibility"
> >> > until the heat death of the universe.

> >> People screaming "backward compatibility" for each and every reason can 
> >> indeed be a problem.

> > Yes, but it's a difficult problem.  I would be screaming if somebody
> > suggested removing the bindings C-o or C-M-o, for example.  I use these
> > all the time.  But if I were the only user of them, it would be
> > difficult to argue for their retention in the default key map.

> I still think we need to find a better binding for C-o, FWIW.
> I recognize I'm in the minority on this position though, but still, I
> think I've used C-o maybe once or twice ever.

> What do you use it for?

I'm not all that sure, come to think of it.  ;-)  I think I use it to get
the RH side of a text line "out of the way" before typing more in.
Inserting an extra argument into a Lisp form is something I do a fair
amount, but then I usually use C-M-o, leaving the moved part of the line
at the same indentation, making it easier to reverse the change.

> > On the other hand, C-x w h (highlight-regexp) already has a "more
> > modern" binding M-s h r, so although I wouldn't be enthused about the
> > removal of C-x w h, I wouldn't object to it either.

> What do you think of my previous keybindings-editions proposal?

Er, what would that be?  Has it been in emacs-devel recently?

> >> We should be able to change default key bindings more freely than we do now.

> > Yes, but...  Every time we do this, we're upsetting _sombody_'s work
> > flow.  I don't see any way of getting this increased freedom to change.

> I love how https://xkcd.com/1172/ is about us.

Yes!

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> > In my view, having considered this discussion in full, the benefits of
> > adding these key bindings, favored by several developers, therefore
> > outweigh the perceived drawbacks.
> 
> That "perceived" there is a mistake.  The drawbacks
> are real.  At the very least, such usage is liable
> to provoke a long, withering post from Drew Adams.  ;-)

Stick to your own withering words, please. ;-)

No, I had no intention to reply to Stefan's post.
If that's the decision, so be it.  Not the best
approach, IMO, but it's decided. 

> I think I would agree with the somebody else that
> suggested enabling these keys by a minor mode.

I'm that somebody else, I guess, or at least one
of them.  I also suggested a user option (opt in).
Both have been typical approaches used in the past.

[External] : Re: Proposal: new default bindings for windmove. [Working minor mode]

[Alan Mackenzie]

Hello, Drew.

On Mon, Jul 01, 2024 at 14:43:51 +0000, Drew Adams wrote:
> > > In my view, having considered this discussion in full, the benefits of
> > > adding these key bindings, favored by several developers, therefore
> > > outweigh the perceived drawbacks.

> > That "perceived" there is a mistake.  The drawbacks
> > are real.  At the very least, such usage is liable
> > to provoke a long, withering post from Drew Adams.  ;-)

> Stick to your own withering words, please. ;-)

OK, will do!

> No, I had no intention to reply to Stefan's post.
> If that's the decision, so be it.  Not the best
> approach, IMO, but it's decided. 

> > I think I would agree with the somebody else that
> > suggested enabling these keys by a minor mode.

> I'm that somebody else, I guess, or at least one
> of them.

I thought it was, but wasn't sure.

> I also suggested a user option (opt in).  Both have been typical
> approaches used in the past.

OK, to get the ball rolling, here is a fully functional minor mode which
could easily fit into windmove.el.  It is just lacking a doc string and
a buffer local version, if the latter makes any sense, here.

(define-minor-mode windmove-c-x-4 "Doc string."
  :lighter nil
  (windmove-install-defaults '(?\C-x ?4) nil '((windmove-left left)
                                               (windmove-right right)
                                               (windmove-up up)
                                               (windmove-down down))
                             (null windmove-c-x-4)))

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [External] : Re: Proposal: new default bindings for windmove. [Working minor mode]

[Eli Zaretskii]

> Date: Mon, 1 Jul 2024 18:12:41 +0000
> Cc: Stefan Kangas <stefankangas@gmail.com>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Daniel Colascione <dancol@dancol.org>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> From: Alan Mackenzie <acm@muc.de>
> 
> OK, to get the ball rolling, here is a fully functional minor mode which
> could easily fit into windmove.el.  It is just lacking a doc string and
> a buffer local version, if the latter makes any sense, here.
> 
> (define-minor-mode windmove-c-x-4 "Doc string."
>   :lighter nil
>   (windmove-install-defaults '(?\C-x ?4) nil '((windmove-left left)
>                                                (windmove-right right)
>                                                (windmove-up up)
>                                                (windmove-down down))
>                              (null windmove-c-x-4)))

Thanks, but there is already windmove-mode, so adding yet another
minor mode for this makes very little sense to me.  It will make an
inelegant situation we already have even uglier.

Re: Proposal: new default bindings for winner and windmove

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

  > The above is true, but it misses the point.  That point is that once the
  > Emacs maintenance team has added a _default_ binding, that can never in
  > the future be changed.

That is true to a large extent, but not entirely.  We have changed
global Emacs key bindings quite a few times.

-- 
Dr Richard Stallman (https://stallman.org)
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: new default bindings for winner and windmove

[Daniel Colascione]

Stefan Kangas <stefankangas@gmail.com> writes:
> Thus, I don't think I see any compelling reason not to go ahead with
> this change.  I would propose that we now start discussing the specifics
> of how to go about doing that (patches, proposed alternative solutions).

How's this?

commit 0af9a3225fe0d8771772ee510abd122d2881b211
Author: Daniel Colascione <dancol@dancol.org>
Date:   Mon Jul 1 19:17:10 2024 -0400

    Directional bindings for windmove
    
    * doc/emacs/windows.texi (Other Window): Describe new
    directional bindings.
    
    * etc/tutorials/TUTORIAL: Describe new directional bindings.
    
    * lisp/windmove.el: Bind C-x 4 followed by an arrow key to the
    corresponding windmove commands.

diff --git a/doc/emacs/windows.texi b/doc/emacs/windows.texi
index 5ad6850fed9..581f74833d3 100644
--- a/doc/emacs/windows.texi
+++ b/doc/emacs/windows.texi
@@ -185,6 +185,27 @@ Other Window
 back and finish supplying the minibuffer argument that is requested.
 @xref{Minibuffer Edit}.
 
+@kindex C-x 4 LEFT
+@kindex C-x 4 RIGHT
+@kindex C-x 4 UP
+@kindex C-x 4 DOWN
+
+Using the keyboard, you can switch windows directionally by typing
+@kbd{C-x 4} followed by an arrow key.  Emacs determines the direction of
+movement using the geometry of windows on the screen rather than history
+of recently-selected windows, so these commands may often by less
+surprising than @kbd{C-x o} above.
+
+@kindex C-x 4 S-LEFT
+@kindex C-x 4 S-RIGHT
+@kindex C-x 4 S-UP
+@kindex C-x 4 S-DOWN
+
+These commands are like the other directional movement commands, except
+that Emacs, instead of moving point to the window in the desired
+direction, moves the whole buffer state, as if taking the current buffer
+and moving it to the desired window.
+
 @findex next-window-any-frame
 The @code{other-window} command will normally only switch to the next
 window in the current frame (unless otherwise configured).  If you
diff --git a/etc/tutorials/TUTORIAL b/etc/tutorials/TUTORIAL
index 4718e0d9430..daba3e4615f 100644
--- a/etc/tutorials/TUTORIAL
+++ b/etc/tutorials/TUTORIAL
@@ -907,6 +907,11 @@ cursor which blinks when you are not typing.  The other windows have
 their own cursor positions; if you are running Emacs in a graphical
 display, those cursors are drawn as unblinking hollow boxes.
 
+You can also use arrow keys prefixed by C-x 4 to move
+between windows directionally.
+
+>> Type C-x 4 <up> to move to the window above the current one.
+
 The command C-M-v is very useful when you are editing text in one
 window and using the other window just for reference.  Without leaving
 the selected window, you can scroll the text in the other window with
diff --git a/lisp/windmove.el b/lisp/windmove.el
index b4e77102abd..db3b52393bf 100644
--- a/lisp/windmove.el
+++ b/lisp/windmove.el
@@ -854,6 +854,23 @@ windmove-swap-states-default-keybindings
   :type windmove--default-keybindings-type
   :version "28.1")
 
+;;;###autoload
+(define-key ctl-x-4-map [left] 'windmove-left)
+;;;###autoload
+(define-key ctl-x-4-map [right] 'windmove-right)
+;;;###autoload
+(define-key ctl-x-4-map [up] 'windmove-up)
+;;;###autoload
+(define-key ctl-x-4-map [down] 'windmove-down)
+;;;###autoload
+(define-key ctl-x-4-map [(shift left)] 'windmove-swap-states-left)
+;;;###autoload
+(define-key ctl-x-4-map [(shift right)] 'windmove-swap-states-right)
+;;;###autoload
+(define-key ctl-x-4-map [(shift up)] 'windmove-swap-states-up)
+;;;###autoload
+(define-key ctl-x-4-map [(shift down)] 'windmove-swap-states-down)
+
 \f
 (provide 'windmove)
 

Re: Proposal: new default bindings for winner and windmove

[Po Lu via Emacs development discussions.]

Daniel Colascione <dancol@dancol.org> writes:

> +;;;###autoload
> +(define-key ctl-x-4-map [left] 'windmove-left)
> +;;;###autoload
> +(define-key ctl-x-4-map [right] 'windmove-right)
> +;;;###autoload
> +(define-key ctl-x-4-map [up] 'windmove-up)
> +;;;###autoload
> +(define-key ctl-x-4-map [down] 'windmove-down)
> +;;;###autoload
> +(define-key ctl-x-4-map [(shift left)] 'windmove-swap-states-left)
> +;;;###autoload
> +(define-key ctl-x-4-map [(shift right)] 'windmove-swap-states-right)
> +;;;###autoload
> +(define-key ctl-x-4-map [(shift up)] 'windmove-swap-states-up)
> +;;;###autoload
> +(define-key ctl-x-4-map [(shift down)] 'windmove-swap-states-down)
> +
>  \f
>  (provide 'windmove)
>  

Disabling windmove-mode must disable these bindings as well.

Re: Proposal: new default bindings for winner and windmove

[Howard Melman]

Po Lu via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> Daniel Colascione <dancol@dancol.org> writes:
>
>> +;;;###autoload
>> +(define-key ctl-x-4-map [left] 'windmove-left)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [right] 'windmove-right)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [up] 'windmove-up)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [down] 'windmove-down)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [(shift left)] 'windmove-swap-states-left)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [(shift right)] 'windmove-swap-states-right)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [(shift up)] 'windmove-swap-states-up)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [(shift down)] 'windmove-swap-states-down)
>> +
>>  \f
>>  (provide 'windmove)
>>  
>
> Disabling windmove-mode must disable these bindings as well.

and should repeat-mode be supported?

-- 

Howard

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Howard Melman <hmelman@gmail.com>
> Date: Mon, 01 Jul 2024 22:03:38 -0400
> 
> Po Lu via "Emacs development discussions."
> <emacs-devel@gnu.org> writes:
> 
> > Disabling windmove-mode must disable these bindings as well.
> 
> and should repeat-mode be supported?

Maybe it should, but that'd be an enhancement, so it should be
discussed separately, IMO.  One disaster at a time, please.

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

>> +;;;###autoload
>> +(define-key ctl-x-4-map [left] 'windmove-left)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [right] 'windmove-right)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [up] 'windmove-up)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [down] 'windmove-down)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [(shift left)] 'windmove-swap-states-left)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [(shift right)] 'windmove-swap-states-right)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [(shift up)] 'windmove-swap-states-up)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [(shift down)] 'windmove-swap-states-down)
>> +
>>  \f
>>  (provide 'windmove)
>
> Disabling windmove-mode must disable these bindings as well.

Could you explain your reasoning for that?


        Stefan

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

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

> Could you explain your reasoning for that?

Does this need to be explained?  Its doc string states:

  Global minor mode for default windmove commands.

What is the purpose of this major mode, if not to disable "default
windmove commands", whatever that means and whatever we designate as
such?

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

>> Could you explain your reasoning for that?
> Does this need to be explained?  Its doc string states:
>
>   Global minor mode for default windmove commands.
>
> What is the purpose of this major mode, if not to disable "default
> windmove commands", whatever that means and whatever we designate as
> such?

By default, this minor mode does absolutely nothing.  More specifically,
it just activates the `windmove-mode-map` but that keymap is empty.
Turning it off should not affect bindings in other keymaps.

There's a good argument for updating that docstring, tho.


        Stefan

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Po Lu via "Emacs development discussions." <emacs-devel@gnu.org>,
>  Daniel Colascione <dancol@dancol.org>,  Stefan Kangas
>  <stefankangas@gmail.com>
> Date: Tue, 02 Jul 2024 09:04:06 -0400
> 
> >> Could you explain your reasoning for that?
> > Does this need to be explained?  Its doc string states:
> >
> >   Global minor mode for default windmove commands.
> >
> > What is the purpose of this major mode, if not to disable "default
> > windmove commands", whatever that means and whatever we designate as
> > such?
> 
> By default, this minor mode does absolutely nothing.

If it does absolutely nothing, then why did we enable it by default?

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

>> By default, this minor mode does absolutely nothing.
> If it does absolutely nothing, then why did we enable it by default?

It's only "enabled by default" in a trivial sense.
And that's inevitable since it's not even loaded.

(boundp 'windmove-mode) returns nil in a fresh new Emacs session.


        Stefan

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: luangruo@yahoo.com,  emacs-devel@gnu.org,  dancol@dancol.org,
>   stefankangas@gmail.com
> Date: Tue, 02 Jul 2024 10:20:49 -0400
> 
> >> By default, this minor mode does absolutely nothing.
> > If it does absolutely nothing, then why did we enable it by default?
> 
> It's only "enabled by default" in a trivial sense.
> And that's inevitable since it's not even loaded.
> 
> (boundp 'windmove-mode) returns nil in a fresh new Emacs session.

That doesn't really answer my question.

When I proposed to enable the windmove bindings as a side effect of
turning on the mode, I was told that it was already turned on.  If
that is not true, how about going back to that proposal?

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> Cc: Stefan Kangas <stefankangas@gmail.com>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Tue, 02 Jul 2024 09:02:12 +0800
> From:  Po Lu via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> Daniel Colascione <dancol@dancol.org> writes:
> 
> > +;;;###autoload
> > +(define-key ctl-x-4-map [left] 'windmove-left)
> > +;;;###autoload
> > +(define-key ctl-x-4-map [right] 'windmove-right)
> > +;;;###autoload
> > +(define-key ctl-x-4-map [up] 'windmove-up)
> > +;;;###autoload
> > +(define-key ctl-x-4-map [down] 'windmove-down)
> > +;;;###autoload
> > +(define-key ctl-x-4-map [(shift left)] 'windmove-swap-states-left)
> > +;;;###autoload
> > +(define-key ctl-x-4-map [(shift right)] 'windmove-swap-states-right)
> > +;;;###autoload
> > +(define-key ctl-x-4-map [(shift up)] 'windmove-swap-states-up)
> > +;;;###autoload
> > +(define-key ctl-x-4-map [(shift down)] 'windmove-swap-states-down)
> > +
> >  \f
> >  (provide 'windmove)
> >  
> 
> Disabling windmove-mode must disable these bindings as well.

I tend to agree.

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On July 2, 2024 8:18:47 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> Cc: Stefan Kangas <stefankangas@gmail.com>,  Stefan Monnier
>>  <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
>> Date: Tue, 02 Jul 2024 09:02:12 +0800
>> From:  Po Lu via "Emacs development discussions." <emacs-devel@gnu.org>
>> 
>> Daniel Colascione <dancol@dancol.org> writes:
>> 
>> > +;;;###autoload
>> > +(define-key ctl-x-4-map [left] 'windmove-left)
>> > +;;;###autoload
>> > +(define-key ctl-x-4-map [right] 'windmove-right)
>> > +;;;###autoload
>> > +(define-key ctl-x-4-map [up] 'windmove-up)
>> > +;;;###autoload
>> > +(define-key ctl-x-4-map [down] 'windmove-down)
>> > +;;;###autoload
>> > +(define-key ctl-x-4-map [(shift left)] 'windmove-swap-states-left)
>> > +;;;###autoload
>> > +(define-key ctl-x-4-map [(shift right)] 'windmove-swap-states-right)
>> > +;;;###autoload
>> > +(define-key ctl-x-4-map [(shift up)] 'windmove-swap-states-up)
>> > +;;;###autoload
>> > +(define-key ctl-x-4-map [(shift down)] 'windmove-swap-states-down)
>> > +
>> >  \f>
>> >  (provide 'windmove)
>> >  
>> 
>> Disabling windmove-mode must disable these bindings as well.
>
>I tend to agree.

What use would it be to disable these bindings?

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> Date: Tue, 02 Jul 2024 08:52:54 -0400
> From: Daniel Colascione <dancol@dancol.org>
> CC: stefankangas@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> 
> 
> On July 2, 2024 8:18:47 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Cc: Stefan Kangas <stefankangas@gmail.com>,  Stefan Monnier
> >>  <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> >> Date: Tue, 02 Jul 2024 09:02:12 +0800
> >> From:  Po Lu via "Emacs development discussions." <emacs-devel@gnu.org>
> >> 
> >> Daniel Colascione <dancol@dancol.org> writes:
> >> 
> >> > +;;;###autoload
> >> > +(define-key ctl-x-4-map [left] 'windmove-left)
> >> > +;;;###autoload
> >> > +(define-key ctl-x-4-map [right] 'windmove-right)
> >> > +;;;###autoload
> >> > +(define-key ctl-x-4-map [up] 'windmove-up)
> >> > +;;;###autoload
> >> > +(define-key ctl-x-4-map [down] 'windmove-down)
> >> > +;;;###autoload
> >> > +(define-key ctl-x-4-map [(shift left)] 'windmove-swap-states-left)
> >> > +;;;###autoload
> >> > +(define-key ctl-x-4-map [(shift right)] 'windmove-swap-states-right)
> >> > +;;;###autoload
> >> > +(define-key ctl-x-4-map [(shift up)] 'windmove-swap-states-up)
> >> > +;;;###autoload
> >> > +(define-key ctl-x-4-map [(shift down)] 'windmove-swap-states-down)
> >> > +
> >> >  \f>
> >> >  (provide 'windmove)
> >> >  
> >> 
> >> Disabling windmove-mode must disable these bindings as well.
> >
> >I tend to agree.
> 
> What use would it be to disable these bindings?

It's cleaner, IMO: disabling a mode cleans up after the mode.  Not an
"over my dead body" kind of issue, obviously, but still.

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On July 2, 2024 9:34:27 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 02 Jul 2024 08:52:54 -0400
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: stefankangas@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> 
>> 
>> 
>> On July 2, 2024 8:18:47 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> Cc: Stefan Kangas <stefankangas@gmail.com>,  Stefan Monnier
>> >>  <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
>> >> Date: Tue, 02 Jul 2024 09:02:12 +0800
>> >> From:  Po Lu via "Emacs development discussions." <emacs-devel@gnu.org>
>> >> 
>> >> Daniel Colascione <dancol@dancol.org> writes:
>> >> 
>> >> > +;;;###autoload
>> >> > +(define-key ctl-x-4-map [left] 'windmove-left)
>> >> > +;;;###autoload
>> >> > +(define-key ctl-x-4-map [right] 'windmove-right)
>> >> > +;;;###autoload
>> >> > +(define-key ctl-x-4-map [up] 'windmove-up)
>> >> > +;;;###autoload
>> >> > +(define-key ctl-x-4-map [down] 'windmove-down)
>> >> > +;;;###autoload
>> >> > +(define-key ctl-x-4-map [(shift left)] 'windmove-swap-states-left)
>> >> > +;;;###autoload
>> >> > +(define-key ctl-x-4-map [(shift right)] 'windmove-swap-states-right)
>> >> > +;;;###autoload
>> >> > +(define-key ctl-x-4-map [(shift up)] 'windmove-swap-states-up)
>> >> > +;;;###autoload
>> >> > +(define-key ctl-x-4-map [(shift down)] 'windmove-swap-states-down)
>> >> > +
>> >> >  \f>>
>> >> >  (provide 'windmove)
>> >> >  
>> >> 
>> >> Disabling windmove-mode must disable these bindings as well.
>> >
>> >I tend to agree.
>> 
>> What use would it be to disable these bindings?
>
>It's cleaner, IMO: disabling a mode cleans up after the mode.  Not an
>"over my dead body" kind of issue, obviously, but still.

It's not a mode though. As Stefan points out, the mode does nothing, which means it probably doesn't make a lot of sense to read too much into the mode being there.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> Date: Tue, 02 Jul 2024 09:53:15 -0400
> From: Daniel Colascione <dancol@dancol.org>
> CC: luangruo@yahoo.com, stefankangas@gmail.com, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> 
> >> What use would it be to disable these bindings?
> >
> >It's cleaner, IMO: disabling a mode cleans up after the mode.  Not an
> >"over my dead body" kind of issue, obviously, but still.
> 
> It's not a mode though.

Well, I think it should be a mode.

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On July 2, 2024 10:15:08 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 02 Jul 2024 09:53:15 -0400
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: luangruo@yahoo.com, stefankangas@gmail.com, monnier@iro.umontreal.ca,
>>  emacs-devel@gnu.org
>> 
>> >> What use would it be to disable these bindings?
>> >
>> >It's cleaner, IMO: disabling a mode cleans up after the mode.  Not an
>> >"over my dead body" kind of issue, obviously, but still.
>> 
>> It's not a mode though.
>
>Well, I think it should be a mode.


Why?

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> Date: Tue, 02 Jul 2024 10:41:03 -0400
> From: Daniel Colascione <dancol@dancol.org>
> CC: luangruo@yahoo.com, stefankangas@gmail.com, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> 
> 
> 
> On July 2, 2024 10:15:08 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Tue, 02 Jul 2024 09:53:15 -0400
> >> From: Daniel Colascione <dancol@dancol.org>
> >> CC: luangruo@yahoo.com, stefankangas@gmail.com, monnier@iro.umontreal.ca,
> >>  emacs-devel@gnu.org
> >> 
> >> >> What use would it be to disable these bindings?
> >> >
> >> >It's cleaner, IMO: disabling a mode cleans up after the mode.  Not an
> >> >"over my dead body" kind of issue, obviously, but still.
> >> 
> >> It's not a mode though.
> >
> >Well, I think it should be a mode.
> 
> 
> Why?

I explained that in another message.

Once again: I won't mount the barricades over this.  If you insist on
doing it this way and no other way, so be it.  I tried to explain why
I won't be too happy about it; feel free to do whatever you want with
that, including nothing at all.

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 02/07/2024 15:18, Eli Zaretskii wrote:
>> Cc: Stefan Kangas <stefankangas@gmail.com>,  Stefan Monnier
>>   <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
>> Date: Tue, 02 Jul 2024 09:02:12 +0800
>> From:  Po Lu via "Emacs development discussions." <emacs-devel@gnu.org>
>>
>> Daniel Colascione <dancol@dancol.org> writes:
>>
>>> +;;;###autoload
>>> +(define-key ctl-x-4-map [left] 'windmove-left)
>>> +;;;###autoload
>>> +(define-key ctl-x-4-map [right] 'windmove-right)
>>> +;;;###autoload
>>> +(define-key ctl-x-4-map [up] 'windmove-up)
>>> +;;;###autoload
>>> +(define-key ctl-x-4-map [down] 'windmove-down)
>>> +;;;###autoload
>>> +(define-key ctl-x-4-map [(shift left)] 'windmove-swap-states-left)
>>> +;;;###autoload
>>> +(define-key ctl-x-4-map [(shift right)] 'windmove-swap-states-right)
>>> +;;;###autoload
>>> +(define-key ctl-x-4-map [(shift up)] 'windmove-swap-states-up)
>>> +;;;###autoload
>>> +(define-key ctl-x-4-map [(shift down)] 'windmove-swap-states-down)
>>> +
>>>   \f
>>>   (provide 'windmove)
>>>   
>>
>> Disabling windmove-mode must disable these bindings as well.
> 
> I tend to agree.

The most straightforward path toward this might be:

- Set the option windmove-default-keybindings to the new set (like 
above) by default.
- Actually enable windmove-mode by default, which will load the package. 
But also set up the keymap filled by the previous item.
- We might also change the function windmove-default-keybindings so that 
is clears up the previous bindings (saved to the value of the option 
with the same name). I think that also was one of your concerns.

The apparent downside is that the package will have to be loaded before 
any of the commands are used for the first time.

Re: Proposal: new default bindings for winner and windmove

[Hovav Shacham]

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

On Tue, Jul 2, 2024, at 5:28 PM, Dmitry Gutov wrote:

> - Set the option windmove-default-keybindings to the new set (like 
> above) by default.

No, that's not reasonable -- that would mean that the shift-arrow keybindings are lost, and (as I pointed out upthread) they have been the bindings for this functionality since the 1980s.

-hs.

[-- Attachment #2: Type: text/html, Size: 680 bytes --]

Re: Proposal: new default bindings for winner and windmove

[Juri Linkov]

>> Thus, I don't think I see any compelling reason not to go ahead with
>> this change.  I would propose that we now start discussing the specifics
>> of how to go about doing that (patches, proposed alternative solutions).
>
> How's this?
>
> +@kindex C-x 4 LEFT
> +@kindex C-x 4 RIGHT
> +@kindex C-x 4 UP
> +@kindex C-x 4 DOWN

I can't believe someone might want to use such long key sequences
for one of the most frequent actions.  It's even longer than
'C-x o' it's supposed to improve.  I think there are no better keys
for switching windows than arrows with a modifier.

Since all keybindings in the 'C-x 4' keymap are for commands
that display a buffer in another window, 'C-x 4 LEFT/...'
could do the same to display the buffer of the next command
in the specified window.

Re: Proposal: new default bindings for winner and windmove

[Yuri Khan]

On Tue, 2 Jul 2024 at 13:59, Juri Linkov <juri@linkov.net> wrote:
> > +@kindex C-x 4 LEFT
> > +@kindex C-x 4 RIGHT
> > +@kindex C-x 4 UP
> > +@kindex C-x 4 DOWN
>
> I can't believe someone might want to use such long key sequences
> for one of the most frequent actions.  It's even longer than
> 'C-x o' it's supposed to improve.  I think there are no better keys
> for switching windows than arrows with a modifier.

My feeling exactly. C-x o is already too long.

Moreover, the modifier involved cannot be a common one, because Shift
is occupied by region selection, Ctrl and Alt with word movement.
Also, the windmove modifier in Emacs needs to be the same as the pane
switching modifier in screen/tmux/kitty and different from that of i3,
and that is something that only the end user can set up for themself.
And I don’t even know a solution for Emacs in a terminal multiplexer,
because there are not enough modifiers.

Re: Proposal: new default bindings for winner and windmove

[Juri Linkov]

>> > +@kindex C-x 4 DOWN
>>
>> I can't believe someone might want to use such long key sequences
>> for one of the most frequent actions.  It's even longer than
>> 'C-x o' it's supposed to improve.  I think there are no better keys
>> for switching windows than arrows with a modifier.
>
> My feeling exactly. C-x o is already too long.
>
> Moreover, the modifier involved cannot be a common one, because Shift
> is occupied by region selection, Ctrl and Alt with word movement.

Alas, common modifiers are not available indeed,
thus need to resort to Super/Hyper like I'm using:

  (setq-default
   windmove-default-keybindings             '(nil super)
   windmove-swap-states-default-keybindings '(nil super shift)
   windmove-display-default-keybindings     '(nil super meta)
   windmove-delete-default-keybindings      `(,(kbd "C-x") super))

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On July 2, 2024 2:50:38 AM EDT, Juri Linkov <juri@linkov.net> wrote:
>>> Thus, I don't think I see any compelling reason not to go ahead with
>>> this change.  I would propose that we now start discussing the specifics
>>> of how to go about doing that (patches, proposed alternative solutions).
>>
>> How's this?
>>
>> +@kindex C-x 4 LEFT
>> +@kindex C-x 4 RIGHT
>> +@kindex C-x 4 UP
>> +@kindex C-x 4 DOWN
>
>I can't believe someone might want to use such long key sequences
>for one of the most frequent actions.  It's even longer than
>'C-x o' it's supposed to improve. 

It's an improvement on C-x o for some use cases because it's more predictable, not because it's shorter. Besides, the key sequence isn't even that hard to type. Have you tried it?

> I think there are no better keys
>for switching windows than arrows with a modifier.

I use these and they're fine. The problem with binding a modifier with bare arrow keys is that all sorts of customizations and modes bind these already. C-x 4 is vacant, logical, and short enough.

>Since all keybindings in the 'C-x 4' keymap are for commands
>that display a buffer in another window, 'C-x 4 LEFT/...'
>could do the same to display the buffer of the next command
>in the specified window.

Such a command doesn't exist and doesn't sound particularly useful to me. Putting window management under C-x 4 makes logical sense. 

Re: Proposal: new default bindings for winner and windmove

[Juri Linkov]

>>> +@kindex C-x 4 DOWN
>>
>>I can't believe someone might want to use such long key sequences
>>for one of the most frequent actions.  It's even longer than
>>'C-x o' it's supposed to improve.
>
> It's an improvement on C-x o for some use cases because it's more
> predictable, not because it's shorter.  Besides, the key sequence
> isn't even that hard to type.  Have you tried it?

Press and hold the Control key, press the x key on the bottom row,
release the Control key, press the 4 key on the top row, press
an arrow key on the keypad.  OTOH, with a modifier: press and
hold the modifier key, press an arrow, release the modifier key.

>> I think there are no better keys
>>for switching windows than arrows with a modifier.
>
> I use these and they're fine.  The problem with binding a modifier
> with bare arrow keys is that all sorts of customizations and modes
> bind these already.  C-x 4 is vacant, logical, and short enough.

So you personally use a modifier, and propose a long key sequence
that nobody will use?

>>Since all keybindings in the 'C-x 4' keymap are for commands
>>that display a buffer in another window, 'C-x 4 LEFT/...'
>>could do the same to display the buffer of the next command
>>in the specified window.
>
> Such a command doesn't exist and doesn't sound particularly useful to me.

It's 'windmove-display-default-keybindings'.  It's less frequently used
than 'windmove-default-keybindings', so a longer key sequence
like 'C-x 4 DOWN' would be fine for 'windmove-display-in-direction'.

> Putting window management under C-x 4 makes logical sense.

We already have a new keymap for window management under C-x w.
Whereas C-x 4 is for buffer display.  Therefore it makes more sense
to put 'windmove-display-default-keybindings' under C-x 4.

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On July 2, 2024 12:32:07 PM EDT, Juri Linkov <juri@linkov.net> wrote:
>>>> +@kindex C-x 4 DOWN
>>>
>>>I can't believe someone might want to use such long key sequences
>>>for one of the most frequent actions.  It's even longer than
>>>'C-x o' it's supposed to improve.
>>
>> It's an improvement on C-x o for some use cases because it's more
>> predictable, not because it's shorter.  Besides, the key sequence
>> isn't even that hard to type.  Have you tried it?
>
>Press and hold the Control key, press the x key on the bottom row,
>release the Control key, press the 4 key on the top row, press
>an arrow key on the keypad.  OTOH, with a modifier: press and
>hold the modifier key, press an arrow, release the modifier key.

Counting keystrokes gives a misleading picture of key binding complexity. Try it yourself: C-x 4 LEFT. The left hand invokes the familiar C-x, then glides up to hit 4 with no further coordination. The right hand hits an arrow key as another familiar action. C-x 4 LEFT might seem long, but I find it a lot more fluid than things like M-j in practice.


>
>>> I think there are no better keys
>>>for switching windows than arrows with a modifier.
>>
>> I use these and they're fine.  The problem with binding a modifier
>> with bare arrow keys is that all sorts of customizations and modes
>> bind these already.  C-x 4 is vacant, logical, and short enough.
>
>So you personally use a modifier, and propose a long key sequence
>that nobody will use?

No. I use the keys I've proposed.



>
>>>Since all keybindings in the 'C-x 4' keymap are for commands
>>>that display a buffer in another window, 'C-x 4 LEFT/...'
>>>could do the same to display the buffer of the next command
>>>in the specified window.
>>
>> Such a command doesn't exist and doesn't sound particularly useful to me.
>
>It's 'windmove-display-default-keybindings'.  It's less frequently used
>than 'windmove-default-keybindings', so a longer key sequence
>like 'C-x 4 DOWN' would be fine for 'windmove-display-in-direction'.

That seems like a lot of extra steps for something conceptually simple.


>
>> Putting window management under C-x 4 makes logical sense.
>
>We already have a new keymap for window management under C-x w.
>Whereas C-x 4 is for buffer display.  Therefore it makes more sense
>to put 'windmove-display-default-keybindings' under C-x 4.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Tue, 02 Jul 2024 09:50:38 +0300
> 
> >> Thus, I don't think I see any compelling reason not to go ahead with
> >> this change.  I would propose that we now start discussing the specifics
> >> of how to go about doing that (patches, proposed alternative solutions).
> >
> > How's this?
> >
> > +@kindex C-x 4 LEFT
> > +@kindex C-x 4 RIGHT
> > +@kindex C-x 4 UP
> > +@kindex C-x 4 DOWN
> 
> I can't believe someone might want to use such long key sequences
> for one of the most frequent actions.  It's even longer than
> 'C-x o' it's supposed to improve.  I think there are no better keys
> for switching windows than arrows with a modifier.

You don't need to use them if you don't like them.  windmove offers
other, much shorter, bindings as an option.  I don't see a reason to
argue about this aspect of the proposal.

Re: Proposal: new default bindings for winner and windmove

[Alfred M. Szmidt]

   >> Thus, I don't think I see any compelling reason not to go ahead with
   >> this change.  I would propose that we now start discussing the specifics
   >> of how to go about doing that (patches, proposed alternative solutions).
   >
   > How's this?
   >
   > +@kindex C-x 4 LEFT
   > +@kindex C-x 4 RIGHT
   > +@kindex C-x 4 UP
   > +@kindex C-x 4 DOWN

   I can't believe someone might want to use such long key sequences
   for one of the most frequent actions.  It's even longer than
   'C-x o' it's supposed to improve.  I think there are no better keys
   for switching windows than arrows with a modifier.

Arrow keys with a modifier are already generally bound to movement
already, and it would be weird if they switched windows...

That C-x 4 <left> .. etc are 'long' reminds me of when GNU Emacs
changed many of the register based keybindings (C-x g, C-x x, C-x s
and C-x j ...) to 'long' ones (C-x r ...).  People got used to using
those, though maybe register usage in Emacs fell out of favour, I
don't know.


The benefit is that C-x 5 <left> could in theory be used to move
between frames, and would match things quite nicley.

Some keybindings to navigate between frame or windows seems like a
very useful thing, even if they are somewhat long they would make
writing keyboard macros slightly easier (for example).  And it seems
that C-x 4 <left> etc are the ones that are available, and seem to be
the most logical if they are to be added compared to repurposing
things like M-<left> .. which would break other peoples workflows who
depend on the default bindings.


   Since all keybindings in the 'C-x 4' keymap are for commands
   that display a buffer in another window, 'C-x 4 LEFT/...'
   could do the same to display the buffer of the next command
   in the specified window.

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 02/07/2024 09:50, Juri Linkov wrote:
>>> Thus, I don't think I see any compelling reason not to go ahead with
>>> this change.  I would propose that we now start discussing the specifics
>>> of how to go about doing that (patches, proposed alternative solutions).
>> How's this?
>>
>> +@kindex C-x 4 LEFT
>> +@kindex C-x 4 RIGHT
>> +@kindex C-x 4 UP
>> +@kindex C-x 4 DOWN
> I can't believe someone might want to use such long key sequences
> for one of the most frequent actions.  It's even longer than
> 'C-x o' it's supposed to improve.  I think there are no better keys
> for switching windows than arrows with a modifier.

I'm going to ask a dangerous question: do people use the existing 
bindings for "C-x <right>" and "C-x <left>"?

Re: Proposal: new default bindings for winner and windmove

[Alfred M. Szmidt]

   On 02/07/2024 09:50, Juri Linkov wrote:
   >>> Thus, I don't think I see any compelling reason not to go ahead with
   >>> this change.  I would propose that we now start discussing the specifics
   >>> of how to go about doing that (patches, proposed alternative solutions).
   >> How's this?
   >>
   >> +@kindex C-x 4 LEFT
   >> +@kindex C-x 4 RIGHT
   >> +@kindex C-x 4 UP
   >> +@kindex C-x 4 DOWN
   > I can't believe someone might want to use such long key sequences
   > for one of the most frequent actions.  It's even longer than
   > 'C-x o' it's supposed to improve.  I think there are no better keys
   > for switching windows than arrows with a modifier.

   I'm going to ask a dangerous question: do people use the existing 
   bindings for "C-x <right>" and "C-x <left>"?

Absolutely; C-x <up> and C-x <down> would be interesting things to bind something to...

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> Date: Tue, 2 Jul 2024 21:03:43 +0300
> Cc: Stefan Kangas <stefankangas@gmail.com>,
>  Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > I can't believe someone might want to use such long key sequences
> > for one of the most frequent actions.  It's even longer than
> > 'C-x o' it's supposed to improve.  I think there are no better keys
> > for switching windows than arrows with a modifier.
> 
> I'm going to ask a dangerous question: do people use the existing 
> bindings for "C-x <right>" and "C-x <left>"?

Yes.

Re: Proposal: new default bindings for winner and windmove

[Yuri Khan]

On Wed, 3 Jul 2024 at 01:04, Dmitry Gutov <dmitry@gutov.dev> wrote:

> I'm going to ask a dangerous question: do people use the existing
> bindings for "C-x <right>" and "C-x <left>"?

No. These implement navigation through a list of a hundred or two,
where you see one item at a time, and navigate one item at a time, and
all this using a non-repeatable key.

Compare Ibuffer, where you see a whole page of items, can navigate one
item at a time with arrows, one page at a time with PgUp/PgDn, or use
isearch.

Most of the times I switch buffers with C-x <right> or C-x <left> is
by mistake when I don’t wait long enough between a cua-mode cut and a
cursor motion.

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 02/07/2024 21:30, Yuri Khan wrote:
> On Wed, 3 Jul 2024 at 01:04, Dmitry Gutov <dmitry@gutov.dev> wrote:
> 
>> I'm going to ask a dangerous question: do people use the existing
>> bindings for "C-x <right>" and "C-x <left>"?
> 
> No. These implement navigation through a list of a hundred or two,
> where you see one item at a time, and navigate one item at a time, and
> all this using a non-repeatable key.
> 
> Compare Ibuffer, where you see a whole page of items, can navigate one
> item at a time with arrows, one page at a time with PgUp/PgDn, or use
> isearch.

Off topic, but in theory the same bindings could be used for a 
"transient" command which (perhaps with a help of repeat-mode) keeps 
rendering the list of buffers e.g. using Ibuffer with the current 
highlighted, until you press something other than <left> or <right>.

Although, to keep the contents of the current buffer displayed, the 
buffers menu would have to be in some sort of popup.

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> Off topic, but in theory the same bindings could be used for a
> "transient" command which (perhaps with a help of repeat-mode) keeps
> rendering the list of buffers e.g. using Ibuffer with the current
> highlighted, until you press something other than <left> or <right>.
> 
> Although, to keep the contents of the current buffer displayed, the
> buffers menu would have to be in some sort of popup.

(As you say, OT.)

With Icicles, when you use any command that
acts on a buffer, prompting for its name with
completion, you can cycle among the choices
matching your current minibuffer input (act
on the buffers or just show info about them).

When you cycle, the mode-line of buffer
*Completions* shows short help/info about the
current candidate buffer for 5 sec (default).

The info shown for a buffer is its mode name,
size in bytes, and file visited (if any):

 Mode: Emacs-Lisp, Bytes: 25429, File: ~/foo/bar.el

Not quite the same as showing Ibuffer, but
similar to what you describe.

This is in fact general, for any kind of
completion candidates.  The info for other
kinds of candidates is different.  For things
with doc strings it's typically the first
line of the candidate's doc string.

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

Apropos using something like Icicles for
cycling and choosing (and there are other
frameworks besides Icicles - even vanilla
Emacs offers enough to get the job done):

Q: Why is completion superior to cycling for
accessing different choices?

1. You can cycle (duh).
2. You can filter, reducing the choice space
   (including the cycling space) on the fly.
3. You can access choices directly (what we
   used to call "random access").
4. You can see/show additional, related info
   about individual candidates (or groups of
   candidates).
5. You can sort candidates in different ways,
   which means changing the eyeball-searching
   order and the cycling order.
6. A single, command-specific key to initiate,
   but can stick to the same (e.g. standard)
   keys for cycling/choosing.  IOW, only the
   initial key need be different (acts like a
   prefix key).

#6 means:

Instead of N key sequences for cycling among
(1) buffers, (2) windows, ... (N) whatevers,
you just need a single key (simple or complex
- doesn't really matter) for each such command.

No need to dedicate N key sequences to such
things, arguing over whether this or that
really deserves a default binding etc.

Regardless of what windmove, winner, winslow,
winthrop, windchill, wince, windbreaker,
windhover, windjammer, windsurfer, windmill,
or ... actually does, consider giving it a
_completion_ UI instead.  Not knowing the
particulars, I'm guessing you'd win bigtime
- see #1-6, above.
___

"Cycling Completions", here:

https://www.emacswiki.org/emacs/Icicles_-_Cycling_Completions

says this about thinking that cycling is only
about #1:

 Do not become a cycling drone!  Input some text
 to narrow the set of candidates, before cycling
 among them to choose one.  This is a good habit
 to adopt, generally, in Icicles.  Most of the
 power of Icicles comes in your ability to filter
 a set of candidates...

 Cycling and filtering work hand in hand.  If the
 set of candidates is small to begin with, then
 just cycling might be quick enough – that's the
 case if you move among a small set of buffers,
 for instance.  But with Icicles you can profitably
 use cycling on even a very large set of candidates
 – by filtering the set first.

(#1-6 are not only about Icicles, per se.  It's
about leveraging _completion_.)
___

Q: When is completion _not_ a better way to cycle?

A: When it's about incrementing/decrementing
something, not choosing among named things.

For that, one general library is Do Re Mi:

https://www.emacswiki.org/emacs/DoReMi

(I assume there are other general libraries for
this kind of thing.)

From that page:

 In case you’re interested, here’s how the idea
 of Do Re Mi came to me.  I had ‘C-M-’ up, down, 
 left, and right arrow keys assigned to commands 
 ‘shrink-frame’, ‘enlarge-frame’,
 ‘shrink-frame-horizontally’, and
 ‘enlarge-frame-horizontally’ from library
 frame-cmds.el.

 But then I saw a use for another command that
 could also be usefully bound to an arrow key to
 take advantage of press-and-hold for incremental
 change of some kind.

 And another.

 My key combinations with the arrow keys being
 limited, it occurred to me that I needed a key
 sequence (command) that would put me in a mode
 where the arrow keys would be temporarily bound
 to some (repeatable) action.

[ Maybe a bit like transient.el, or repeat-mode,
  or this function that I use a lot to repeatify
  a given command:

  (defun repeat-command (command)
    "Repeat COMMAND."
    (require 'repeat)
    (let ((repeat-previous-repeated-command  command)
          (repeat-message-function           #'ignore)
          (last-repeatable-command           'repeat))
      (repeat nil))))
]

Re: Proposal: new default bindings for winner and windmove

[Yuri Khan]

On Wed, 3 Jul 2024 at 18:15, Dmitry Gutov <dmitry@gutov.dev> wrote:

> Off topic, but in theory the same bindings could be used for a
> "transient" command which (perhaps with a help of repeat-mode) keeps
> rendering the list of buffers e.g. using Ibuffer with the current
> highlighted, until you press something other than <left> or <right>.

At that point, the <prefix> <left> and <prefix> <right> keys no longer
make sense, because, clearly, buffers are arranged in a vertical list
rather than a horizontal strip.

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

> At that point, the <prefix> <left> and <prefix> <right> keys no longer
> make sense, because, clearly, buffers are arranged in a vertical list
> rather than a horizontal strip.

AFAIK these commands cycle through the list of buffers, so I think of it
as a circle, and I'd rather use keys like <clockwise> and
<counter-clockwise>.


        Stefan


PS: Sorry, couldn't resists.

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 03/07/2024 16:53, Stefan Monnier wrote:
>> At that point, the <prefix> <left> and <prefix> <right> keys no longer
>> make sense, because, clearly, buffers are arranged in a vertical list
>> rather than a horizontal strip.
> AFAIK these commands cycle through the list of buffers, so I think of it
> as a circle, and I'd rather use keys like <clockwise> and
> <counter-clockwise>.

Sounds like PgUp and PgDown could have been a good fit.

Re: Proposal: new default bindings for winner and windmove

[Yuri Khan]

On Wed, 3 Jul 2024 at 20:53, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > At that point, the <prefix> <left> and <prefix> <right> keys no longer
> > make sense, because, clearly, buffers are arranged in a vertical list
> > rather than a horizontal strip.
>
> AFAIK these commands cycle through the list of buffers, so I think of it
> as a circle, and I'd rather use keys like <clockwise> and
> <counter-clockwise>.

You probably said that in jest, but there are in fact many keyboards
that feature rotary encoders that can emit key or mouse events when
turned, and people do configure those to switch tabs in browsers,
among other uses. (On the wire, it still looks like Ctrl+PgUp and
Ctrl+PgDn, because that’s what browsers and editors expect.)

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Wed, 3 Jul 2024 at 20:53, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>
>> > At that point, the <prefix> <left> and <prefix> <right> keys no longer
>> > make sense, because, clearly, buffers are arranged in a vertical list
>> > rather than a horizontal strip.
>>
>> AFAIK these commands cycle through the list of buffers, so I think of it
>> as a circle, and I'd rather use keys like <clockwise> and
>> <counter-clockwise>.
>
> You probably said that in jest, but there are in fact many keyboards
> that feature rotary encoders that can emit key or mouse events when
> turned, and people do configure those to switch tabs in browsers,
> among other uses. (On the wire, it still looks like Ctrl+PgUp and
> Ctrl+PgDn, because that’s what browsers and editors expect.)

Yeah. I've been meaning to hook up a https://monogramcc.com/ to Emacs
for a while now.  There'd be something viscerally satisfying about going
back and forth in undo history using that large rotary dial.  Sadly, no
Linux drivers yet. :-(

Re: Proposal: new default bindings for winner and windmove

[John ff]

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

mlllm/(l

⁣​

On 3 Jul 2024, 17:27, at 17:27, Daniel Colascione <dancol@dancol.org> wrote:
>Yuri Khan <yuri.v.khan@gmail.com> writes:
>
>> On Wed, 3 Jul 2024 at 20:53, Stefan Monnier
><monnier@iro.umontreal.ca> wrote:
>>>
>>> > At that point, the <prefix> <left> and <prefix> <right> keys no
>longer
>>> > make sense, because, clearly, buffers are arranged in a vertical
>list
>>> > rather than a horizontal strip.
>>>
>>> AFAIK these commands cycle through the list of buffers, so I think
>of it
>>> as a circle, and I'd rather use keys like <clockwise> and
>>> <counter-clockwise>.
>>
>> You probably said that in jest, but there are in fact many keyboards
>> that feature rotary encoders that can emit key or mouse events when
>> turned, and people do configure those to switch tabs in browsers,
>> among other uses. (On the wire, it still looks like Ctrl+PgUp and
>> Ctrl+PgDn, because that’s what browsers and editors expect.)
>
>Yeah. I've been meaning to hook up a https://monogramcc.com/ to Emacs
>for a while now.  There'd be something viscerally satisfying about
>going
>back and forth in undo history using that large rotary dial.  Sadly, no
>Linux drivers yet. :-(

[-- Attachment #2: Type: text/html, Size: 2008 bytes --]

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Dmitry.

On Tue, Jul 02, 2024 at 21:03:43 +0300, Dmitry Gutov wrote:
> On 02/07/2024 09:50, Juri Linkov wrote:
> >>> Thus, I don't think I see any compelling reason not to go ahead with
> >>> this change.  I would propose that we now start discussing the specifics
> >>> of how to go about doing that (patches, proposed alternative solutions).
> >> How's this?

> >> +@kindex C-x 4 LEFT
> >> +@kindex C-x 4 RIGHT
> >> +@kindex C-x 4 UP
> >> +@kindex C-x 4 DOWN
> > I can't believe someone might want to use such long key sequences
> > for one of the most frequent actions.  It's even longer than
> > 'C-x o' it's supposed to improve.  I think there are no better keys
> > for switching windows than arrows with a modifier.

> I'm going to ask a dangerous question: do people use the existing 
> bindings for "C-x <right>" and "C-x <left>"?

That's next-buffer and previous-buffer.  No, I don't use them, mainly
through not being aware of them.  They could come in handy, though, when
looking at N buffers in M windows, with M < N.  I've been in that
position quite a lot in the last few months.

Why do we not have next-buffer-other-window and
previous-buffer-other-window?  Why don't we have ....-other-frame?  I
think the likelihood that users have written such functions for
themselves and bound them to C-x 4/5 <left>/<right> is high.

This brings me back to my point about being careful about making default
bindings.  It would seem next/previous-buffer-other-window, whether yet
existing or not, have a greater claim on C-x 4 <right>/<left> than the
windmove functions... Also that we should preserve C-x 4 <up>/<down> for
the -other-window versions of some future C-x <up>/<down> commands.

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

> > I'm going to ask a dangerous question: do people use the existing
> > bindings for "C-x <right>" and "C-x <left>"?
> 
> That's next-buffer and previous-buffer.  No, I don't use them, mainly
> through not being aware of them.  They could come in handy, though, when
> looking at N buffers in M windows, with M < N.  I've been in that
> position quite a lot in the last few months.
> 
> Why do we not have next-buffer-other-window and
> previous-buffer-other-window?  Why don't we have
> ....-other-frame?

In my 40 years of using Emacs, I don't think
I've ever used `next-buffer' and the like.

I use `C-x b' (or `C-x 4 b' or `C-x 5 b') and
`M-n' or `M-p'.  As a bonus, the prompt tells
me what the buffer will be.

I'm happy to see that `mouse-1' and `mouse-3'
on the current buffer name in a mode-line do
the previous and next buffer things, by
default.  That's especially good for newbies,
I imagine.  But I have no need for the `C-x'
followed by arrow-key bindings.

That said, I'm not suggesting we bind those
keys to something else.  (I wouldn't mind if
they were "liberated" to the No-Default Free
List, however.)

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 02/07/2024 21:34, Alan Mackenzie wrote:
> This brings me back to my point about being careful about making default
> bindings.  It would seem next/previous-buffer-other-window, whether yet
> existing or not, have a greater claim on C-x 4 <right>/<left> than the
> windmove functions...

If they were useful enough, perhaps - though that doesn't seem to be the 
case, given that those commands haven't been added by now.

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Dmitry.

On Tue, Jul 02, 2024 at 22:53:00 +0300, Dmitry Gutov wrote:
> On 02/07/2024 21:34, Alan Mackenzie wrote:
> > This brings me back to my point about being careful about making default
> > bindings.  It would seem next/previous-buffer-other-window, whether yet
> > existing or not, have a greater claim on C-x 4 <right>/<left> than the
> > windmove functions...

> If they were useful enough, perhaps - though that doesn't seem to be the 
> case, given that those commands haven't been added by now.

That would be a judgment call, not something black and white.  My guess
is that next/previous-buffer-other-window would be very useful indeed to
a small number of users.  Much like the windmove functions will be
useful to some users.

I can't help but think we're shooting ourselves in the foot by having
C-x <binding> and C-x 4 <binding> which don't do the same thing in
different windows.

Which brings us back again to the question why C-x 4 <arrow>?  As
somebody (you, perhaps?) mentioned, we have C-x w bindings for window
operations.  Why not C-x w <arrow> instead?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Dmitry.
>
> On Tue, Jul 02, 2024 at 22:53:00 +0300, Dmitry Gutov wrote:
>> On 02/07/2024 21:34, Alan Mackenzie wrote:
>> > This brings me back to my point about being careful about making default
>> > bindings.  It would seem next/previous-buffer-other-window, whether yet
>> > existing or not, have a greater claim on C-x 4 <right>/<left> than the
>> > windmove functions...
>
>> If they were useful enough, perhaps - though that doesn't seem to be the 
>> case, given that those commands haven't been added by now.
>
> That would be a judgment call, not something black and white.  My guess
> is that next/previous-buffer-other-window would be very useful indeed to
> a small number of users.  Much like the windmove functions will be
> useful to some users.
>
> I can't help but think we're shooting ourselves in the foot by having
> C-x <binding> and C-x 4 <binding> which don't do the same thing in
> different windows.
>
> Which brings us back again to the question why C-x 4 <arrow>?  As
> somebody (you, perhaps?) mentioned, we have C-x w bindings for window
> operations.  Why not C-x w <arrow> instead?

I think 4 is slightly easier to hit than w because the former is at the
top of the keyboard and so has a Fitts's law advantage.  That said, I
could support C-x w <arrow> too.  I'll change my private bindings and
my patch and see how it goes.

Re: Proposal: new default bindings for winner and windmove

[Juri Linkov]

>> Why not C-x w <arrow> instead?
>
> I think 4 is slightly easier to hit than w because the former is at the
> top of the keyboard and so has a Fitts's law advantage.  That said, I
> could support C-x w <arrow> too.  I'll change my private bindings and
> my patch and see how it goes.

We could design a submaps scheme for all windmove commands, e.g.:

C-x w <arrow>   - windmove-default-keybindings
C-x w 4 <arrow> - windmove-display-default-keybindings
C-x w d <arrow> - windmove-delete-default-keybindings
C-x w m <arrow> - windmove-swap-states-default-keybindings
C-x w s <arrow> - windmove-split-default-keybindings

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

Hi Alan,

On 02/07/2024 23:12, Alan Mackenzie wrote:

> Which brings us back again to the question why C-x 4 <arrow>?  As
> somebody (you, perhaps?) mentioned, we have C-x w bindings for window
> operations.  Why not C-x w <arrow> instead?

Not me, but 'C-x w' might be reasonable. I think the main downside is 
the presence of the different binding for 'C-x C-w', meaning that typing 
'C-x w' too quickly might lead to the wrong result. And one would likely 
type the window related sequences quickly.

Re: Proposal: new default bindings for winner and windmove

[Juri Linkov]

> I'm going to ask a dangerous question: do people use the existing bindings
> for "C-x <right>" and "C-x <left>"?

Oh, you are touching a subject that has no solution.
Here is the problem: 'C-x <left>' and 'C-x <right>' are
very useful keys to navigate to the last used buffer and back.
But tab-line-mode-map has to rebind them to navigate
to the left/right tab on the tab-line.  However,
going to the last used buffer is still useful
even for the tab-line.  But there are no free keys
for both features - it's a lose-lose situation.

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 02/07/2024 21:37, Juri Linkov wrote:
>> I'm going to ask a dangerous question: do people use the existing bindings
>> for "C-x <right>" and "C-x <left>"?
> 
> Oh, you are touching a subject that has no solution.
> Here is the problem: 'C-x <left>' and 'C-x <right>' are
> very useful keys to navigate to the last used buffer and back.
> But tab-line-mode-map has to rebind them to navigate
> to the left/right tab on the tab-line.  However,
> going to the last used buffer is still useful
> even for the tab-line.  But there are no free keys
> for both features - it's a lose-lose situation.

Perhaps tabs could use C-x <up> and <down>? As somewhat related, tab 
switching in browsers and multi-tab terminal emulators is often bound to 
C-PgUp and C-PgDown. Those bindings are taken, but the directions could 
be reused.

Anyway, I personally like C-x <arrows> sequences for window navigation - 
it's my second choice after M-<arrows>. But it doesn't seem like an 
option, alas.

Re: Proposal: new default bindings for winner and windmove

[Juri Linkov]

>> Here is the problem: 'C-x <left>' and 'C-x <right>' are
>> very useful keys to navigate to the last used buffer and back.
>> But tab-line-mode-map has to rebind them to navigate
>> to the left/right tab on the tab-line.  However,
>> going to the last used buffer is still useful
>> even for the tab-line.  But there are no free keys
>> for both features - it's a lose-lose situation.
>
> Perhaps tabs could use C-x <up> and <down>? As somewhat related, tab
> switching in browsers and multi-tab terminal emulators is often bound to
> C-PgUp and C-PgDown. Those bindings are taken, but the directions could be
> reused.

ISTR <up> means backward, but this is not as mnemonic as <left>
on an imaginable horizontal line of buffers visited from left to right.
Also tried to use different modifiers for <left> and <right>:

C-x <left>    - tab-line-switch-to-prev-tab
C-x <right>   - tab-line-switch-to-next-tab
C-x C-<left>  - previous-buffer
C-x C-<right> - next-buffer

but these keybindings were intended to be identical.

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

> ISTR <up> means backward, but this is not as mnemonic as <left>
> on an imaginable horizontal line of buffers visited from left to right.

I suspect this is L2R-centric.
[ Of course, Emacs is very strongly English-centric anyway, so we should
  probably not worry too much about it.  ]


        Stefan

Re: Proposal: new default bindings for winner and windmove

[Visuwesh]

[செவ்வாய் ஜூலை 02, 2024] Dmitry Gutov wrote:

> On 02/07/2024 09:50, Juri Linkov wrote:
>> I can't believe someone might want to use such long key sequences
>> for one of the most frequent actions.  It's even longer than
>> 'C-x o' it's supposed to improve.  I think there are no better keys
>> for switching windows than arrows with a modifier.
>
> I'm going to ask a dangerous question: do people use the existing
> bindings for "C-x <right>" and "C-x <left>"?

Yes, daily.  It is very handy with repeat-mode to quickly switch buffers
back-and-forth.
[ I like that they use arrow keys since I usually need to navigate to
  another location in the buffer upon switching.  ]

Re: Proposal: new default bindings for winner and windmove

[Philip Kaludercic]

Daniel Colascione <dancol@dancol.org> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>> Thus, I don't think I see any compelling reason not to go ahead with
>> this change.  I would propose that we now start discussing the specifics
>> of how to go about doing that (patches, proposed alternative solutions).
>
> How's this?
>
> commit 0af9a3225fe0d8771772ee510abd122d2881b211
> Author: Daniel Colascione <dancol@dancol.org>
> Date:   Mon Jul 1 19:17:10 2024 -0400
>
>     Directional bindings for windmove
>     
>     * doc/emacs/windows.texi (Other Window): Describe new
>     directional bindings.
>     
>     * etc/tutorials/TUTORIAL: Describe new directional bindings.
>     
>     * lisp/windmove.el: Bind C-x 4 followed by an arrow key to the
>     corresponding windmove commands.
>
> diff --git a/doc/emacs/windows.texi b/doc/emacs/windows.texi
> index 5ad6850fed9..581f74833d3 100644
> --- a/doc/emacs/windows.texi
> +++ b/doc/emacs/windows.texi
> @@ -185,6 +185,27 @@ Other Window
>  back and finish supplying the minibuffer argument that is requested.
>  @xref{Minibuffer Edit}.
>  
> +@kindex C-x 4 LEFT
> +@kindex C-x 4 RIGHT
> +@kindex C-x 4 UP
> +@kindex C-x 4 DOWN
> +
> +Using the keyboard, you can switch windows directionally by typing
> +@kbd{C-x 4} followed by an arrow key.  Emacs determines the direction of
> +movement using the geometry of windows on the screen rather than history
> +of recently-selected windows, so these commands may often by less
> +surprising than @kbd{C-x o} above.
> +
> +@kindex C-x 4 S-LEFT
> +@kindex C-x 4 S-RIGHT
> +@kindex C-x 4 S-UP
> +@kindex C-x 4 S-DOWN
> +
> +These commands are like the other directional movement commands, except
> +that Emacs, instead of moving point to the window in the desired
> +direction, moves the whole buffer state, as if taking the current buffer
> +and moving it to the desired window.
> +
>  @findex next-window-any-frame
>  The @code{other-window} command will normally only switch to the next
>  window in the current frame (unless otherwise configured).  If you
> diff --git a/etc/tutorials/TUTORIAL b/etc/tutorials/TUTORIAL
> index 4718e0d9430..daba3e4615f 100644
> --- a/etc/tutorials/TUTORIAL
> +++ b/etc/tutorials/TUTORIAL
> @@ -907,6 +907,11 @@ cursor which blinks when you are not typing.  The other windows have
>  their own cursor positions; if you are running Emacs in a graphical
>  display, those cursors are drawn as unblinking hollow boxes.
>  
> +You can also use arrow keys prefixed by C-x 4 to move
> +between windows directionally.
> +
> +>> Type C-x 4 <up> to move to the window above the current one.
> +
>  The command C-M-v is very useful when you are editing text in one
>  window and using the other window just for reference.  Without leaving
>  the selected window, you can scroll the text in the other window with
> diff --git a/lisp/windmove.el b/lisp/windmove.el
> index b4e77102abd..db3b52393bf 100644
> --- a/lisp/windmove.el
> +++ b/lisp/windmove.el
> @@ -854,6 +854,23 @@ windmove-swap-states-default-keybindings
>    :type windmove--default-keybindings-type
>    :version "28.1")
>  
> +;;;###autoload
> +(define-key ctl-x-4-map [left] 'windmove-left)
> +;;;###autoload
> +(define-key ctl-x-4-map [right] 'windmove-right)
> +;;;###autoload
> +(define-key ctl-x-4-map [up] 'windmove-up)
> +;;;###autoload
> +(define-key ctl-x-4-map [down] 'windmove-down)

You could use

  (setopt windmove-default-keybindings (list (kbd "C-x 4"))),

which would allow for the bindings to be disabled more easily.

> +;;;###autoload
> +(define-key ctl-x-4-map [(shift left)] 'windmove-swap-states-left)
> +;;;###autoload
> +(define-key ctl-x-4-map [(shift right)] 'windmove-swap-states-right)
> +;;;###autoload
> +(define-key ctl-x-4-map [(shift up)] 'windmove-swap-states-up)
> +;;;###autoload
> +(define-key ctl-x-4-map [(shift down)] 'windmove-swap-states-down)
> +
>  \f
>  (provide 'windmove)
>  
>
>

-- 
	Philip Kaludercic on peregrine

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On July 2, 2024 3:08:28 AM EDT, Philip Kaludercic <philipk@posteo.net> wrote:
>Daniel Colascione <dancol@dancol.org> writes:
>
>> Stefan Kangas <stefankangas@gmail.com> writes:
>>> Thus, I don't think I see any compelling reason not to go ahead with
>>> this change.  I would propose that we now start discussing the specifics
>>> of how to go about doing that (patches, proposed alternative solutions).
>>
>> How's this?
>>
>> commit 0af9a3225fe0d8771772ee510abd122d2881b211
>> Author: Daniel Colascione <dancol@dancol.org>
>> Date:   Mon Jul 1 19:17:10 2024 -0400
>>
>>     Directional bindings for windmove
>>     
>>     * doc/emacs/windows.texi (Other Window): Describe new
>>     directional bindings.
>>     
>>     * etc/tutorials/TUTORIAL: Describe new directional bindings.
>>     
>>     * lisp/windmove.el: Bind C-x 4 followed by an arrow key to the
>>     corresponding windmove commands.
>>
>> diff --git a/doc/emacs/windows.texi b/doc/emacs/windows.texi
>> index 5ad6850fed9..581f74833d3 100644
>> --- a/doc/emacs/windows.texi
>> +++ b/doc/emacs/windows.texi
>> @@ -185,6 +185,27 @@ Other Window
>>  back and finish supplying the minibuffer argument that is requested.
>>  @xref{Minibuffer Edit}.
>>  
>> +@kindex C-x 4 LEFT
>> +@kindex C-x 4 RIGHT
>> +@kindex C-x 4 UP
>> +@kindex C-x 4 DOWN
>> +
>> +Using the keyboard, you can switch windows directionally by typing
>> +@kbd{C-x 4} followed by an arrow key.  Emacs determines the direction of
>> +movement using the geometry of windows on the screen rather than history
>> +of recently-selected windows, so these commands may often by less
>> +surprising than @kbd{C-x o} above.
>> +
>> +@kindex C-x 4 S-LEFT
>> +@kindex C-x 4 S-RIGHT
>> +@kindex C-x 4 S-UP
>> +@kindex C-x 4 S-DOWN
>> +
>> +These commands are like the other directional movement commands, except
>> +that Emacs, instead of moving point to the window in the desired
>> +direction, moves the whole buffer state, as if taking the current buffer
>> +and moving it to the desired window.
>> +
>>  @findex next-window-any-frame
>>  The @code{other-window} command will normally only switch to the next
>>  window in the current frame (unless otherwise configured).  If you
>> diff --git a/etc/tutorials/TUTORIAL b/etc/tutorials/TUTORIAL
>> index 4718e0d9430..daba3e4615f 100644
>> --- a/etc/tutorials/TUTORIAL
>> +++ b/etc/tutorials/TUTORIAL
>> @@ -907,6 +907,11 @@ cursor which blinks when you are not typing.  The other windows have
>>  their own cursor positions; if you are running Emacs in a graphical
>>  display, those cursors are drawn as unblinking hollow boxes.
>>  
>> +You can also use arrow keys prefixed by C-x 4 to move
>> +between windows directionally.
>> +
>> +>> Type C-x 4 <up> to move to the window above the current one.
>> +
>>  The command C-M-v is very useful when you are editing text in one
>>  window and using the other window just for reference.  Without leaving
>>  the selected window, you can scroll the text in the other window with
>> diff --git a/lisp/windmove.el b/lisp/windmove.el
>> index b4e77102abd..db3b52393bf 100644
>> --- a/lisp/windmove.el
>> +++ b/lisp/windmove.el
>> @@ -854,6 +854,23 @@ windmove-swap-states-default-keybindings
>>    :type windmove--default-keybindings-type
>>    :version "28.1")
>>  
>> +;;;###autoload
>> +(define-key ctl-x-4-map [left] 'windmove-left)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [right] 'windmove-right)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [up] 'windmove-up)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [down] 'windmove-down)
>
>You could use
>
>  (setopt windmove-default-keybindings (list (kbd "C-x 4"))),
>
>which would allow for the bindings to be disabled more easily.

They're global keybindings. If you don't want these keys bound to these commands, bind them to something else. There's no case for "disabling" them.


>
>> +;;;###autoload
>> +(define-key ctl-x-4-map [(shift left)] 'windmove-swap-states-left)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [(shift right)] 'windmove-swap-states-right)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [(shift up)] 'windmove-swap-states-up)
>> +;;;###autoload
>> +(define-key ctl-x-4-map [(shift down)] 'windmove-swap-states-down)
>> +
>>  \f>
>>  (provide 'windmove)
>>  
>>
>>
>

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Daniel.

On Tue, Jul 02, 2024 at 07:46:41 -0400, Daniel Colascione wrote:


> On July 2, 2024 3:08:28 AM EDT, Philip Kaludercic <philipk@posteo.net> wrote:
> >Daniel Colascione <dancol@dancol.org> writes:

> >> Stefan Kangas <stefankangas@gmail.com> writes:
> >>> Thus, I don't think I see any compelling reason not to go ahead with
> >>> this change.  I would propose that we now start discussing the specifics
> >>> of how to go about doing that (patches, proposed alternative solutions).

> >> How's this?

> >> commit 0af9a3225fe0d8771772ee510abd122d2881b211
> >> Author: Daniel Colascione <dancol@dancol.org>
> >> Date:   Mon Jul 1 19:17:10 2024 -0400

> >>     Directional bindings for windmove

> >>     * doc/emacs/windows.texi (Other Window): Describe new
> >>     directional bindings.

> >>     * etc/tutorials/TUTORIAL: Describe new directional bindings.

> >>     * lisp/windmove.el: Bind C-x 4 followed by an arrow key to the
> >>     corresponding windmove commands.

> >> diff --git a/doc/emacs/windows.texi b/doc/emacs/windows.texi
> >> index 5ad6850fed9..581f74833d3 100644
> >> --- a/doc/emacs/windows.texi
> >> +++ b/doc/emacs/windows.texi
> >> @@ -185,6 +185,27 @@ Other Window
> >>  back and finish supplying the minibuffer argument that is requested.
> >>  @xref{Minibuffer Edit}.

> >> +@kindex C-x 4 LEFT
> >> +@kindex C-x 4 RIGHT
> >> +@kindex C-x 4 UP
> >> +@kindex C-x 4 DOWN
> >> +
> >> +Using the keyboard, you can switch windows directionally by typing
> >> +@kbd{C-x 4} followed by an arrow key.  Emacs determines the direction of
> >> +movement using the geometry of windows on the screen rather than history
> >> +of recently-selected windows, so these commands may often by less
> >> +surprising than @kbd{C-x o} above.
> >> +
> >> +@kindex C-x 4 S-LEFT
> >> +@kindex C-x 4 S-RIGHT
> >> +@kindex C-x 4 S-UP
> >> +@kindex C-x 4 S-DOWN
> >> +
> >> +These commands are like the other directional movement commands, except
> >> +that Emacs, instead of moving point to the window in the desired
> >> +direction, moves the whole buffer state, as if taking the current buffer
> >> +and moving it to the desired window.
> >> +

I thought we were just talking about four bindings, here.  Now you want
to create a full eight new bindings.  That sounds a bit excessive.

Also S-LEFT, etc., won't work in unenhanced ttys.

How often do users really want to "drag" a buffer into a different
window?  I would have thought, far less often than just moving point.  So
why not use a prefix arg here, thus saving bindings and making them more
often usable?  C-u C-x 4 LEFT, etc. would do the job nicely.

> >>  @findex next-window-any-frame
> >>  The @code{other-window} command will normally only switch to the next
> >>  window in the current frame (unless otherwise configured).  If you
> >> diff --git a/etc/tutorials/TUTORIAL b/etc/tutorials/TUTORIAL
> >> index 4718e0d9430..daba3e4615f 100644
> >> --- a/etc/tutorials/TUTORIAL
> >> +++ b/etc/tutorials/TUTORIAL
> >> @@ -907,6 +907,11 @@ cursor which blinks when you are not typing.  The other windows have
> >>  their own cursor positions; if you are running Emacs in a graphical
> >>  display, those cursors are drawn as unblinking hollow boxes.

> >> +You can also use arrow keys prefixed by C-x 4 to move
> >> +between windows directionally.
> >> +
> >> +>> Type C-x 4 <up> to move to the window above the current one.
> >> +
> >>  The command C-M-v is very useful when you are editing text in one
> >>  window and using the other window just for reference.  Without leaving
> >>  the selected window, you can scroll the text in the other window with
> >> diff --git a/lisp/windmove.el b/lisp/windmove.el
> >> index b4e77102abd..db3b52393bf 100644
> >> --- a/lisp/windmove.el
> >> +++ b/lisp/windmove.el
> >> @@ -854,6 +854,23 @@ windmove-swap-states-default-keybindings
> >>    :type windmove--default-keybindings-type
> >>    :version "28.1")

> >> +;;;###autoload
> >> +(define-key ctl-x-4-map [left] 'windmove-left)
> >> +;;;###autoload
> >> +(define-key ctl-x-4-map [right] 'windmove-right)
> >> +;;;###autoload
> >> +(define-key ctl-x-4-map [up] 'windmove-up)
> >> +;;;###autoload
> >> +(define-key ctl-x-4-map [down] 'windmove-down)

> >You could use

> >  (setopt windmove-default-keybindings (list (kbd "C-x 4"))),

> >which would allow for the bindings to be disabled more easily.

> They're global keybindings. If you don't want these keys bound to these
> commands, bind them to something else. There's no case for "disabling"
> them.

Oh, there is!  Some users will have C-x 4 LEFT, etc., bound buffer
locally to do other things.  They will expect a beep and an error message
if they type it in a "wrong" buffer.  That functionality would be lost.


> >> +;;;###autoload
> >> +(define-key ctl-x-4-map [(shift left)] 'windmove-swap-states-left)
> >> +;;;###autoload
> >> +(define-key ctl-x-4-map [(shift right)] 'windmove-swap-states-right)
> >> +;;;###autoload
> >> +(define-key ctl-x-4-map [(shift up)] 'windmove-swap-states-up)
> >> +;;;###autoload
> >> +(define-key ctl-x-4-map [(shift down)] 'windmove-swap-states-down)
> >> +
> >>  \f>
> >>  (provide 'windmove)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 02/07/2024 16:31, Alan Mackenzie wrote:
>>>   (setopt windmove-default-keybindings (list (kbd "C-x 4"))),
>>> which would allow for the bindings to be disabled more easily.
>> They're global keybindings. If you don't want these keys bound to these
>> commands, bind them to something else. There's no case for "disabling"
>> them.
> Oh, there is!  Some users will have C-x 4 LEFT, etc., bound buffer
> locally to do other things.  They will expect a beep and an error message
> if they type it in a "wrong" buffer.  That functionality would be lost.

That's really the main argument against adding new bindings.

But it's really an argument against adding any bindings to those 
sequences, at all, ever.

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

On July 2, 2024 9:31:35 AM EDT, Alan Mackenzie <acm@muc.de> wrote:
>Hello, Daniel.
>
>On Tue, Jul 02, 2024 at 07:46:41 -0400, Daniel Colascione wrote:
>
>
>> On July 2, 2024 3:08:28 AM EDT, Philip Kaludercic <philipk@posteo.net> wrote:
>> >Daniel Colascione <dancol@dancol.org> writes:
>
>> >> Stefan Kangas <stefankangas@gmail.com> writes:
>> >>> Thus, I don't think I see any compelling reason not to go ahead with
>> >>> this change.  I would propose that we now start discussing the specifics
>> >>> of how to go about doing that (patches, proposed alternative solutions).
>
>> >> How's this?
>
>> >> commit 0af9a3225fe0d8771772ee510abd122d2881b211
>> >> Author: Daniel Colascione <dancol@dancol.org>
>> >> Date:   Mon Jul 1 19:17:10 2024 -0400
>
>> >>     Directional bindings for windmove
>
>> >>     * doc/emacs/windows.texi (Other Window): Describe new
>> >>     directional bindings.
>
>> >>     * etc/tutorials/TUTORIAL: Describe new directional bindings.
>
>> >>     * lisp/windmove.el: Bind C-x 4 followed by an arrow key to the
>> >>     corresponding windmove commands.
>
>> >> diff --git a/doc/emacs/windows.texi b/doc/emacs/windows.texi
>> >> index 5ad6850fed9..581f74833d3 100644
>> >> --- a/doc/emacs/windows.texi
>> >> +++ b/doc/emacs/windows.texi
>> >> @@ -185,6 +185,27 @@ Other Window
>> >>  back and finish supplying the minibuffer argument that is requested.
>> >>  @xref{Minibuffer Edit}.
>
>> >> +@kindex C-x 4 LEFT
>> >> +@kindex C-x 4 RIGHT
>> >> +@kindex C-x 4 UP
>> >> +@kindex C-x 4 DOWN
>> >> +
>> >> +Using the keyboard, you can switch windows directionally by typing
>> >> +@kbd{C-x 4} followed by an arrow key.  Emacs determines the direction of
>> >> +movement using the geometry of windows on the screen rather than history
>> >> +of recently-selected windows, so these commands may often by less
>> >> +surprising than @kbd{C-x o} above.
>> >> +
>> >> +@kindex C-x 4 S-LEFT
>> >> +@kindex C-x 4 S-RIGHT
>> >> +@kindex C-x 4 S-UP
>> >> +@kindex C-x 4 S-DOWN
>> >> +
>> >> +These commands are like the other directional movement commands, except
>> >> +that Emacs, instead of moving point to the window in the desired
>> >> +direction, moves the whole buffer state, as if taking the current buffer
>> >> +and moving it to the desired window.
>> >> +
>
>I thought we were just talking about four bindings, here.  Now you want
>to create a full eight new bindings.  That sounds a bit excessive.

No? Bindings aren't precious.

>Also S-LEFT, etc., won't work in unenhanced ttys.
>
>How often do users really want to "drag" a buffer into a different
>window?

I do it all the time.


 > I would have thought, far less often than just moving point.  So
>why not use a prefix arg here, thus saving bindings and making them more
>often usable?  C-u C-x 4 LEFT, etc. would do the job nicely.

Because that's more annoying to type and doesn't seem to come with compelling advantages.

>> >>  @findex next-window-any-frame
>> >>  The @code{other-window} command will normally only switch to the next
>> >>  window in the current frame (unless otherwise configured).  If you
>> >> diff --git a/etc/tutorials/TUTORIAL b/etc/tutorials/TUTORIAL
>> >> index 4718e0d9430..daba3e4615f 100644
>> >> --- a/etc/tutorials/TUTORIAL
>> >> +++ b/etc/tutorials/TUTORIAL
>> >> @@ -907,6 +907,11 @@ cursor which blinks when you are not typing.  The other windows have
>> >>  their own cursor positions; if you are running Emacs in a graphical
>> >>  display, those cursors are drawn as unblinking hollow boxes.
>
>> >> +You can also use arrow keys prefixed by C-x 4 to move
>> >> +between windows directionally.
>> >> +
>> >> +>> Type C-x 4 <up> to move to the window above the current one.
>> >> +
>> >>  The command C-M-v is very useful when you are editing text in one
>> >>  window and using the other window just for reference.  Without leaving
>> >>  the selected window, you can scroll the text in the other window with
>> >> diff --git a/lisp/windmove.el b/lisp/windmove.el
>> >> index b4e77102abd..db3b52393bf 100644
>> >> --- a/lisp/windmove.el
>> >> +++ b/lisp/windmove.el
>> >> @@ -854,6 +854,23 @@ windmove-swap-states-default-keybindings
>> >>    :type windmove--default-keybindings-type
>> >>    :version "28.1")
>
>> >> +;;;###autoload
>> >> +(define-key ctl-x-4-map [left] 'windmove-left)
>> >> +;;;###autoload
>> >> +(define-key ctl-x-4-map [right] 'windmove-right)
>> >> +;;;###autoload
>> >> +(define-key ctl-x-4-map [up] 'windmove-up)
>> >> +;;;###autoload
>> >> +(define-key ctl-x-4-map [down] 'windmove-down)
>
>> >You could use
>
>> >  (setopt windmove-default-keybindings (list (kbd "C-x 4"))),
>
>> >which would allow for the bindings to be disabled more easily.
>
>> They're global keybindings. If you don't want these keys bound to these
>> commands, bind them to something else. There's no case for "disabling"
>> them.
>
>Oh, there is!  Some users will have C-x 4 LEFT, etc., bound buffer
>locally to do other things.  They will expect a beep and an error message
>if they type it in a "wrong" buffer.  That functionality would be lost.

This is a general purpose argument against adding any new binding whatsoever. I don't think the absence of a binding should be contractua behavior.


>
>
>> >> +;;;###autoload
>> >> +(define-key ctl-x-4-map [(shift left)] 'windmove-swap-states-left)
>> >> +;;;###autoload
>> >> +(define-key ctl-x-4-map [(shift right)] 'windmove-swap-states-right)
>> >> +;;;###autoload
>> >> +(define-key ctl-x-4-map [(shift up)] 'windmove-swap-states-up)
>> >> +;;;###autoload
>> >> +(define-key ctl-x-4-map [(shift down)] 'windmove-swap-states-down)
>> >> +
>> >>  \f>>
>> >>  (provide 'windmove)
>

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Daniel.

On Tue, Jul 02, 2024 at 09:55:07 -0400, Daniel Colascione wrote:


> On July 2, 2024 9:31:35 AM EDT, Alan Mackenzie <acm@muc.de> wrote:
> >On Tue, Jul 02, 2024 at 07:46:41 -0400, Daniel Colascione wrote:


> >> On July 2, 2024 3:08:28 AM EDT, Philip Kaludercic <philipk@posteo.net> wrote:
> >> >Daniel Colascione <dancol@dancol.org> writes:

> >> >> Stefan Kangas <stefankangas@gmail.com> writes:
> >> >>> Thus, I don't think I see any compelling reason not to go ahead with
> >> >>> this change.  I would propose that we now start discussing the specifics
> >> >>> of how to go about doing that (patches, proposed alternative solutions).

> >> >> How's this?

> >> >> commit 0af9a3225fe0d8771772ee510abd122d2881b211
> >> >> Author: Daniel Colascione <dancol@dancol.org>
> >> >> Date:   Mon Jul 1 19:17:10 2024 -0400

> >> >>     Directional bindings for windmove

> >> >>     * doc/emacs/windows.texi (Other Window): Describe new
> >> >>     directional bindings.

> >> >>     * etc/tutorials/TUTORIAL: Describe new directional bindings.

> >> >>     * lisp/windmove.el: Bind C-x 4 followed by an arrow key to the
> >> >>     corresponding windmove commands.

> >> >> diff --git a/doc/emacs/windows.texi b/doc/emacs/windows.texi
> >> >> index 5ad6850fed9..581f74833d3 100644
> >> >> --- a/doc/emacs/windows.texi
> >> >> +++ b/doc/emacs/windows.texi
> >> >> @@ -185,6 +185,27 @@ Other Window
> >> >>  back and finish supplying the minibuffer argument that is requested.
> >> >>  @xref{Minibuffer Edit}.

> >> >> +@kindex C-x 4 LEFT
> >> >> +@kindex C-x 4 RIGHT
> >> >> +@kindex C-x 4 UP
> >> >> +@kindex C-x 4 DOWN
> >> >> +
> >> >> +Using the keyboard, you can switch windows directionally by typing
> >> >> +@kbd{C-x 4} followed by an arrow key.  Emacs determines the direction of
> >> >> +movement using the geometry of windows on the screen rather than history
> >> >> +of recently-selected windows, so these commands may often by less
> >> >> +surprising than @kbd{C-x o} above.
> >> >> +
> >> >> +@kindex C-x 4 S-LEFT
> >> >> +@kindex C-x 4 S-RIGHT
> >> >> +@kindex C-x 4 S-UP
> >> >> +@kindex C-x 4 S-DOWN
> >> >> +
> >> >> +These commands are like the other directional movement commands, except
> >> >> +that Emacs, instead of moving point to the window in the desired
> >> >> +direction, moves the whole buffer state, as if taking the current buffer
> >> >> +and moving it to the desired window.
> >> >> +

> >I thought we were just talking about four bindings, here.  Now you want
> >to create a full eight new bindings.  That sounds a bit excessive.

> No? Bindings aren't precious.

They most definitely are.  As I pointed out yesterday, once a DEFAULT
binding has been assigned, that default binding can never again be
assigned to a different command.  The Emacs maintenance team has a
limited number of default bindings available for new commands.  It should
assign them wisely, with restraint.

> >Also S-LEFT, etc., won't work in unenhanced ttys.

> >How often do users really want to "drag" a buffer into a different
> >window?

> I do it all the time.

I never do, and only very occassionally find myself wanting to.  Maybe
these are bindings which would be better in your personal setup than in
the default key map.

>  > I would have thought, far less often than just moving point.  So
> >why not use a prefix arg here, thus saving bindings and making them more
> >often usable?  C-u C-x 4 LEFT, etc. would do the job nicely.

> Because that's more annoying to type and doesn't seem to come with
> compelling advantages.

Well, working on ttys, and saving four key bindings for something else
seem pretty compelling to me.

> >> >>  @findex next-window-any-frame
> >> >>  The @code{other-window} command will normally only switch to the next
> >> >>  window in the current frame (unless otherwise configured).  If you
> >> >> diff --git a/etc/tutorials/TUTORIAL b/etc/tutorials/TUTORIAL
> >> >> index 4718e0d9430..daba3e4615f 100644
> >> >> --- a/etc/tutorials/TUTORIAL
> >> >> +++ b/etc/tutorials/TUTORIAL
> >> >> @@ -907,6 +907,11 @@ cursor which blinks when you are not typing.  The other windows have
> >> >>  their own cursor positions; if you are running Emacs in a graphical
> >> >>  display, those cursors are drawn as unblinking hollow boxes.

> >> >> +You can also use arrow keys prefixed by C-x 4 to move
> >> >> +between windows directionally.
> >> >> +
> >> >> +>> Type C-x 4 <up> to move to the window above the current one.
> >> >> +
> >> >>  The command C-M-v is very useful when you are editing text in one
> >> >>  window and using the other window just for reference.  Without leaving
> >> >>  the selected window, you can scroll the text in the other window with
> >> >> diff --git a/lisp/windmove.el b/lisp/windmove.el
> >> >> index b4e77102abd..db3b52393bf 100644
> >> >> --- a/lisp/windmove.el
> >> >> +++ b/lisp/windmove.el
> >> >> @@ -854,6 +854,23 @@ windmove-swap-states-default-keybindings
> >> >>    :type windmove--default-keybindings-type
> >> >>    :version "28.1")

> >> >> +;;;###autoload
> >> >> +(define-key ctl-x-4-map [left] 'windmove-left)
> >> >> +;;;###autoload
> >> >> +(define-key ctl-x-4-map [right] 'windmove-right)
> >> >> +;;;###autoload
> >> >> +(define-key ctl-x-4-map [up] 'windmove-up)
> >> >> +;;;###autoload
> >> >> +(define-key ctl-x-4-map [down] 'windmove-down)

> >> >You could use

> >> >  (setopt windmove-default-keybindings (list (kbd "C-x 4"))),

> >> >which would allow for the bindings to be disabled more easily.

> >> They're global keybindings. If you don't want these keys bound to these
> >> commands, bind them to something else. There's no case for "disabling"
> >> them.

> >Oh, there is!  Some users will have C-x 4 LEFT, etc., bound buffer
> >locally to do other things.  They will expect a beep and an error message
> >if they type it in a "wrong" buffer.  That functionality would be lost.

> This is a general purpose argument against adding any new binding
> whatsoever. I don't think the absence of a binding should be contractua
> behavior.

You might by trying to trap me with your "black and white" arguments
here.  There are shades of grey between black and white.  Your point was:

> There's NO case for "disabling" them [ windmove key bindings ].

, an absolute, dogmatic statement.  I showed it to be wrong.  Nowhere did
I state or imply that my lost functionality argument should prevail over
opposing arguments.  But it should be taken into account whenever adding
new default keybindings.


> >> >> +;;;###autoload
> >> >> +(define-key ctl-x-4-map [(shift left)] 'windmove-swap-states-left)
> >> >> +;;;###autoload
> >> >> +(define-key ctl-x-4-map [(shift right)] 'windmove-swap-states-right)
> >> >> +;;;###autoload
> >> >> +(define-key ctl-x-4-map [(shift up)] 'windmove-swap-states-up)
> >> >> +;;;###autoload
> >> >> +(define-key ctl-x-4-map [(shift down)] 'windmove-swap-states-down)
> >> >> +
> >> >>  \f>>
> >> >>  (provide 'windmove)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Alfred M. Szmidt]

   >> >> +@kindex C-x 4 S-LEFT
   >> >> +@kindex C-x 4 S-RIGHT
   >> >> +@kindex C-x 4 S-UP
   >> >> +@kindex C-x 4 S-DOWN
   >> >> +
   >> >> +These commands are like the other directional movement commands, except
   >> >> +that Emacs, instead of moving point to the window in the desired
   >> >> +direction, moves the whole buffer state, as if taking the current buffer
   >> >> +and moving it to the desired window.
   >> >> +
   >
   >I thought we were just talking about four bindings, here.  Now you want
   >to create a full eight new bindings.  That sounds a bit excessive.

   No? Bindings aren't precious.

They are _very_ precious; specially good ones!  This is descending
into absurdity very quickly... Do you have a infinite keyboard?

   >Also S-LEFT, etc., won't work in unenhanced ttys.
   >
   >How often do users really want to "drag" a buffer into a different
   >window?

   I do it all the time.

In 35+ of using Emacs, I've never had the need to "move" a buffer from
one window or frame to another.

Re: Proposal: new default bindings for winner and windmove

[Eli Zaretskii]

> From: Daniel Colascione <dancol@dancol.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Mon, 01 Jul 2024 19:18:36 -0400
> 
> +Using the keyboard, you can switch windows directionally by typing
> +@kbd{C-x 4} followed by an arrow key.  Emacs determines the direction of
> +movement using the geometry of windows on the screen rather than history
> +of recently-selected windows, so these commands may often by less
> +surprising than @kbd{C-x o} above.                        ^^

Did you mean "be"?

> +@kindex C-x 4 S-LEFT
> +@kindex C-x 4 S-RIGHT
> +@kindex C-x 4 S-UP
> +@kindex C-x 4 S-DOWN
> +
> +These commands are like the other directional movement commands, except
> +that Emacs, instead of moving point to the window in the desired
> +direction, moves the whole buffer state, as if taking the current buffer
> +and moving it to the desired window.

This description needs to be clarified.  Something like (I hope I
understand the full effect of the command):

 These commands switch to a window in the direction of the arrow, like
 @kbd{C-x 4} followed by an arrow key, but they also move the current
 buffer to be displayed in that window.  (The buffer which was
 displayed in that window will be now displayed in the
 previously-selected window, i.e. the two buffers swap their windows.)

> --- a/etc/tutorials/TUTORIAL
> +++ b/etc/tutorials/TUTORIAL
> @@ -907,6 +907,11 @@ cursor which blinks when you are not typing.  The other windows have
>  their own cursor positions; if you are running Emacs in a graphical
>  display, those cursors are drawn as unblinking hollow boxes.
>  
> +You can also use arrow keys prefixed by C-x 4 to move
> +between windows directionally.
> +
> +>> Type C-x 4 <up> to move to the window above the current one.

AFAICT, if the user does exactly what the tutorial says, he/she will
be in the upper window at this point, so "C-x 4 <UP>" will signal an
error.  Perhaps the text should be modified to cater to both
situations, because it is unknown how many times the user will type
"C-x o".

Re: Proposal: new default bindings for winner and windmove

[Stefan Kangas]

Daniel Colascione <dancol@dancol.org> writes:

> How's this?

LGTM, once Stefan's and Eli's comments have been addressed.

It should also be announced in etc/NEWS.

Re: Proposal: new default bindings for winner and windmove

[Liu Hui]

在 2024/7/2 07:18, Daniel Colascione 写道:
> Stefan Kangas <stefankangas@gmail.com> writes:
>> Thus, I don't think I see any compelling reason not to go ahead with
>> this change.  I would propose that we now start discussing the specifics
>> of how to go about doing that (patches, proposed alternative solutions).
> 
> How's this?
> 
> commit 0af9a3225fe0d8771772ee510abd122d2881b211
> Author: Daniel Colascione <dancol@dancol.org>
> Date:   Mon Jul 1 19:17:10 2024 -0400
> 
>      Directional bindings for windmove
>      
>      * doc/emacs/windows.texi (Other Window): Describe new
>      directional bindings.
>      
>      * etc/tutorials/TUTORIAL: Describe new directional bindings.
>      
>      * lisp/windmove.el: Bind C-x 4 followed by an arrow key to the
>      corresponding windmove commands.

How about C-x w (window-prefix-map)?

Re: Proposal: new default bindings for winner and windmove

[Juri Linkov]

> A few years ago, Daniel suggested:
>> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
>> for people automatically, enabled by default.
>
> AFAICT we still don't actually provide any keybindings for the windmove
> commands by default.  Did I miss a controversy about that, or did it
> just fall through the cracks?
>
> [ I mean, I assume there are different opinions about which set of keybindings
>   is the best, but it seems to me that it should not be that hard to
>   find a default set of keybindings that's better than no keybindings
>   at all.  ]

The arrow keys have a good mnemonic for windmove-display-in-direction.

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

On 21.08.2021 22:10, Daniel Colascione wrote:
> Today, winner binds C-c LEFT  and C-c RIGHT for window configuration 
> undo and redo, respectively. This set of bindings has three problems:
> 
>   1) the bindings occupy binding space on important keys, LEFT and 
> RIGHT, for functions that are rarely used,

Frequently used here. I often need to back out of some window management 
mishaps.

> 2) the winner binding space isn't logically connected to window 
> management, and
> 
> 3) the bindings don't work on terminals without LEFT and RIGHT.
> 
> How about we set up these bindings instead?
> 
> C-x 4 C-/ winner-undo
> 
> M-- C-x 4 C-/ winner-redo

Makes sense in theory, but these are not repeatable (though some 
integration with repeat-mode, as well as more advertising of that mode, 
could work around that problem).

I guess my main reservation is that the current bindings are very 
comfortable, and we'd lose the chance to tell the user about them.

Perhaps we could instead add a defcustom which would list both options?

Re: Proposal: new default bindings for winner and windmove

[Boruch Baum]

> From: Eli Zaretskii
> Date: Sun, 22 Aug 2021 09:02:23 +0300
>
> > From: Arthur Miller <arthur.miller@live.com>
> > Date: Sat, 21 Aug 2021 22:20:22 +0200
> >
> > > I'm actually surprised they have key bindings.  How frequently do you
> > > undo/redo window configuration changes?
> > You obviously don't need to call help functions as often as I :).

Adding myself to the list of people who use winner-mode often and are
happy with the keybinding status quo.

> > It is handy to restore back windows after
> > ...

+1

> My solution to the "window configuration issue" is to keep several
> frames, one each for different tasks.  Each frame has windows arranged
> as appropriate for that task, and that configuration rarely if ever
> changes.

As a case in point, I found `ediff' mode very frustrating in that upon
quitting, it would always leave me with an undesirable window
configuration, and I never figured out how to *reliably* automate using
`winner-undo' for that situation. What did work was what you're
suggesting:

   (defun my-ediff-pre ()
     "Stuff to perform before starting any `ediff' session.
   Meant to be an entry in variable `ediff-before-setup-hook'."
     (make-frame-command)
     (set-frame-name "ediff"))

   (defun my-ediff-post ()
     "Stuff to perform after exiting any `ediff' session.
   Meant to be an entry in variable `ediff-quit-hook'."
     (condition-case nil
       (progn
         (select-frame-by-name "ediff")
         (delete-frame))))

   (add-hook 'ediff-before-setup-hook #'my-ediff-pre)
   (add-hook 'ediff-quit-hook #'my-ediff-post 100)

IMO, this should be considered as a default setup for ediff, and the
notion of defaulting to a dedicated frame for certain other specific
tasks should be considered (eg. calendar/diary). BTW, I do this with
packages diredc and crossword.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: Proposal: new default bindings for winner and windmove

[Pedro Andres Aranda Gutierrez]

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

> On Mon, Jul 01, 2024 at 14:25:51 +0300, Dmitry Gutov wrote:
>> Hi Alan,

>> On 01/07/2024 13:07, Alan Mackenzie wrote:
>> > The above is true, but it misses the point.  That point is that once
the
>> > Emacs maintenance team has added a_default_  binding, that can never in
>> > the future be changed.  People will scream "backward compatibility"
>> > until the heat death of the universe.

>> People screaming "backward compatibility" for each and every reason can
>> indeed be a problem.

Backward compatibility should indeed be an issue. If you can't open a line
and
continue editing at the end of the line with one keystroke, as you have
been
doing for the last 30 years (and continue to do) and you are called a
problem,
you may be more than just 'annoyed'.

A bit of respect, please
/PA
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 2890 bytes --]