From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Proposal: new default bindings for winner and windmove Date: Tue, 2 Jul 2024 14:42:55 +0000 Message-ID: References: <875xto7lbn.fsf@dancol.org> <87wmm45l03.fsf@posteo.net> <44819FBF-2B9D-4812-A9A0-F25D500569A5@dancol.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14378"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philip Kaludercic , Stefan Kangas , Stefan Monnier , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 02 16:43:34 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sOejF-0003Xd-Fv for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Jul 2024 16:43:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOeiq-00052K-3K; Tue, 02 Jul 2024 10:43:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sOeik-00050l-17 for emacs-devel@gnu.org; Tue, 02 Jul 2024 10:43:02 -0400 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sOeih-0006ZO-Fj for emacs-devel@gnu.org; Tue, 02 Jul 2024 10:43:01 -0400 Original-Received: (qmail 7894 invoked by uid 3782); 2 Jul 2024 16:42:56 +0200 Original-Received: from muc.de (p4fe15e87.dip0.t-ipconnect.de [79.225.94.135]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 02 Jul 2024 16:42:56 +0200 Original-Received: (qmail 19526 invoked by uid 1000); 2 Jul 2024 14:42:55 -0000 Content-Disposition: inline In-Reply-To: <44819FBF-2B9D-4812-A9A0-F25D500569A5@dancol.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:321168 Archived-At: 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 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 wrote: > >> >Daniel Colascione writes: > >> >> Stefan Kangas 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 > >> >> 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 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) > >> >> + > >> >> >> > >> >> (provide 'windmove) -- Alan Mackenzie (Nuremberg, Germany).