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

[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

[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

[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

[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

[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

[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

[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

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

[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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

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

[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

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

[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

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

> 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

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

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

[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

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

[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

[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

[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

[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

[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

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

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

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

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

[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

[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

[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

[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

[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

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

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

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

[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

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

[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

[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

[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

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

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

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

> 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

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

[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

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

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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

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

[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

[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

[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

[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

[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

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

> 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

[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

[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

[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

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

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

[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

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

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

[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

[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

[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

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

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

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

[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

[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

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

> 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

[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

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