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: [External] : Re: Proposal: new default bindings for winner and windmove

[Drew Adams]

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

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

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

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

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

Re: Proposal: new default bindings for winner and windmove

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