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 07:46:41 -0400 Message-ID: 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="39753"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: K-9 Mail for Android Cc: Stefan Kangas , Stefan Monnier , emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 02 13:47:44 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 1sObz6-000A4o-0f for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Jul 2024 13:47:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sObyU-0004Vw-CG; Tue, 02 Jul 2024 07:47:06 -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 1sObyQ-0004VH-CK for emacs-devel@gnu.org; Tue, 02 Jul 2024 07:47:02 -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 1sObyK-0005io-OC for emacs-devel@gnu.org; Tue, 02 Jul 2024 07:47:02 -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=34rZ0s2q3WVAWj5qaf2fY7H4VNZKc4UNhGe12DLZGLE=; b=ZHagOCZLv5OVHmMtWtjpwyQ+c4 AawJRoFkg2SADCVl2l4n/YV2puG2DEAO03F2W/+esXQOdoHERii1hHby7IHUTLZqQDxpSuklATiLz eP3ZY/NSTgiyQnSAhv7ztxOx8np0wHFpWkhG7hjpHx5gnh7Yvj/DW5ZBtwTVab3MMs3SMxgcpoI2Z KVYmzWX0s7Ky5NzJfPsJ0RZu9m48KtA0UyTNLgQPZWxFgOyjMRsnt90ZcvlvuRfaUuJt/rFAoNKI4 9/gOAldRTvzjh+FGTe1vhRDBr8OwEgAPdJaiCxzA/USVVKi4VS5BiGS6o+euzrX8EshQl++1h7Ncn frRP4Jyw==; Original-Received: from 2603-9001-4203-1ab2-8f2f-ca74-255c-b80b.inf6.spectrum.com ([2603:9001:4203:1ab2:8f2f:ca74:255c:b80b]:59184 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 1sOby6-00030B-Rd; Tue, 02 Jul 2024 07:46:43 -0400 In-Reply-To: <87wmm45l03.fsf@posteo.net> 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, T_SPF_TEMPERROR=0.01 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:321130 Archived-At: On July 2, 2024 3:08:28 AM EDT, Philip Kaludercic w= rote: >Daniel Colascione writes: > >> Stefan Kangas writes: >>> Thus, I don't think I see any compelling reason not to go ahead with >>> this change=2E I would propose that we now start discussing the speci= fics >>> of how to go about doing that (patches, proposed alternative solutions= )=2E >> >> How's this? >> >> commit 0af9a3225fe0d8771772ee510abd122d2881b211 >> Author: Daniel Colascione >> Date: Mon Jul 1 19:17:10 2024 -0400 >> >> Directional bindings for windmove >> =20 >> * doc/emacs/windows=2Etexi (Other Window): Describe new >> directional bindings=2E >> =20 >> * etc/tutorials/TUTORIAL: Describe new directional bindings=2E >> =20 >> * 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 >> =20 >> +@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 directio= n of >> +movement using the geometry of windows on the screen rather than histo= ry >> +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, excep= t >> +that Emacs, instead of moving point to the window in the desired >> +direction, moves the whole buffer state, as if taking the current buff= er >> +and moving it to the desired window=2E >> + >> @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)=2E If you >> 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 Th= e 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 >> =20 >> +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 leavi= ng >> the selected window, you can scroll the text in the other window with >> 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") >> =20 >> +;;;###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 these = commands, bind them to something else=2E There's no case for "disabling" th= em=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) >> =20 >> >> >