Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie <acm@muc.de>]

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