From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Proposal: new default bindings for winner and windmove Date: Tue, 02 Jul 2024 09:55:07 -0400 Message-ID: <44819FBF-2B9D-4812-A9A0-F25D500569A5@dancol.org> References: <875xto7lbn.fsf@dancol.org> <87wmm45l03.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12784"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: K-9 Mail for Android Cc: Philip Kaludercic , Stefan Kangas , Stefan Monnier , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 02 15:55:40 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 1sOdyt-00035c-BP for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Jul 2024 15:55:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOdye-0005B6-40; Tue, 02 Jul 2024 09:55:24 -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 1sOdyc-0005Ai-F0 for emacs-devel@gnu.org; Tue, 02 Jul 2024 09:55:22 -0400 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sOdya-000846-Gj for emacs-devel@gnu.org; Tue, 02 Jul 2024 09:55:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=vTQPjDDV5x75qt1mkF5wlmjuMPJZ4kntfFP2mgyTQ/w=; b=m0+dr+2ARwJ36RXz/NoiY6WD2Z q7CmuD12wTzFBuDpAZNxaOQcI9mOg5mfVxmt+zBZsyfZpsKwF7+LIS6Xdx5cIPfVgNyPn3X3MPauL Jqz0uSH4rO2Kv7Qkg7EK9WD4DSLzVfA0+ng1JVr8Ju/s8zmLVo7dALLiRaw9goGTE9Dm4uEhx+Eao OKYvvdB+/82o+H5IKRf2zQ9bVbP/ncIWeBbR6WK9e4IvnHLFXUKDGUZsPchmmOpAuRPmVRYpHzhmt d+9kx9MZ+HOAYLyTJVRxN+j3lhs2RLhtWZUsE121ljasELY4oTAv3x2OFeXpWhnHe1LOX6Ef3WP3R dXADcvzg==; Original-Received: from 2603-9001-4203-1ab2-05eb-444b-867a-c5cd.inf6.spectrum.com ([2603:9001:4203:1ab2:5eb:444b:867a:c5cd]:38620 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sOdyO-0003MJ-G8; Tue, 02 Jul 2024 09:55:09 -0400 In-Reply-To: Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@dancol.org; helo=dancol.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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:321159 Archived-At: On July 2, 2024 9:31:35 AM EDT, Alan Mackenzie wrote: >Hello, Daniel=2E > >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 wit= h >> >>> this change=2E I would propose that we now start discussing the sp= ecifics >> >>> of how to go about doing that (patches, proposed alternative soluti= ons)=2E > >> >> How's this? > >> >> commit 0af9a3225fe0d8771772ee510abd122d2881b211 >> >> Author: Daniel Colascione >> >> Date: Mon Jul 1 19:17:10 2024 -0400 > >> >> Directional bindings for windmove > >> >> * doc/emacs/windows=2Etexi (Other Window): Describe new >> >> directional bindings=2E > >> >> * etc/tutorials/TUTORIAL: Describe new directional bindings=2E > >> >> * lisp/windmove=2Eel: Bind C-x 4 followed by an arrow key to the >> >> corresponding windmove commands=2E > >> >> diff --git a/doc/emacs/windows=2Etexi b/doc/emacs/windows=2Etexi >> >> index 5ad6850fed9=2E=2E581f74833d3 100644 >> >> --- a/doc/emacs/windows=2Etexi >> >> +++ b/doc/emacs/windows=2Etexi >> >> @@ -185,6 +185,27 @@ Other Window >> >> back and finish supplying the minibuffer argument that is requested= =2E >> >> @xref{Minibuffer Edit}=2E > >> >> +@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=2E Emacs determines the direc= tion of >> >> +movement using the geometry of windows on the screen rather than hi= story >> >> +of recently-selected windows, so these commands may often by less >> >> +surprising than @kbd{C-x o} above=2E >> >> + >> >> +@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, ex= cept >> >> +that Emacs, instead of moving point to the window in the desired >> >> +direction, moves the whole buffer state, as if taking the current b= uffer >> >> +and moving it to the desired window=2E >> >> + > >I thought we were just talking about four bindings, here=2E Now you want >to create a full eight new bindings=2E That sounds a bit excessive=2E No? Bindings aren't precious=2E >Also S-LEFT, etc=2E, won't work in unenhanced ttys=2E > >How often do users really want to "drag" a buffer into a different >window? I do it all the time=2E > I would have thought, far less often than just moving point=2E So >why not use a prefix arg here, thus saving bindings and making them more >often usable? C-u C-x 4 LEFT, etc=2E would do the job nicely=2E Because that's more annoying to type and doesn't seem to come with compell= ing advantages=2E >> >> @findex next-window-any-frame >> >> The @code{other-window} command will normally only switch to the ne= xt >> >> window in the current frame (unless otherwise configured)=2E If yo= u >> >> diff --git a/etc/tutorials/TUTORIAL b/etc/tutorials/TUTORIAL >> >> index 4718e0d9430=2E=2Edaba3e4615f 100644 >> >> --- a/etc/tutorials/TUTORIAL >> >> +++ b/etc/tutorials/TUTORIAL >> >> @@ -907,6 +907,11 @@ cursor which blinks when you are not typing=2E = 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=2E > >> >> +You can also use arrow keys prefixed by C-x 4 to move >> >> +between windows directionally=2E >> >> + >> >> +>> Type C-x 4 to move to the window above the current one=2E >> >> + >> >> The command C-M-v is very useful when you are editing text in one >> >> window and using the other window just for reference=2E Without le= aving >> >> the selected window, you can scroll the text in the other window wi= th >> >> diff --git a/lisp/windmove=2Eel b/lisp/windmove=2Eel >> >> index b4e77102abd=2E=2Edb3b52393bf 100644 >> >> --- a/lisp/windmove=2Eel >> >> +++ b/lisp/windmove=2Eel >> >> @@ -854,6 +854,23 @@ windmove-swap-states-default-keybindings >> >> :type windmove--default-keybindings-type >> >> :version "28=2E1") > >> >> +;;;###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=2E > >> They're global keybindings=2E If you don't want these keys bound to the= se >> commands, bind them to something else=2E There's no case for "disabling= " >> them=2E > >Oh, there is! Some users will have C-x 4 LEFT, etc=2E, bound buffer >locally to do other things=2E They will expect a beep and an error messa= ge >if they type it in a "wrong" buffer=2E That functionality would be lost= =2E This is a general purpose argument against adding any new binding whatsoev= er=2E I don't think the absence of a binding should be contractua behavior= =2E > > >> >> +;;;###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) >> >> + >> >> =0C>> >> >> (provide 'windmove) >