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 18:34:57 +0000 Message-ID: References: <875xto7lbn.fsf@dancol.org> <86ed8ce2mh.fsf@mail.linkov.net> <81b620d7-18a6-4c6e-8517-147a411ee882@gutov.dev> 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="25054"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Juri Linkov , Daniel Colascione , Stefan Kangas , Stefan Monnier , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 02 20:35:42 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 1sOiLu-0006L6-8g for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Jul 2024 20:35:42 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOiLL-00024l-Jx; Tue, 02 Jul 2024 14:35:09 -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 1sOiLH-00024O-Tw for emacs-devel@gnu.org; Tue, 02 Jul 2024 14:35:04 -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 1sOiLE-0000qo-Lu for emacs-devel@gnu.org; Tue, 02 Jul 2024 14:35:02 -0400 Original-Received: (qmail 74424 invoked by uid 3782); 2 Jul 2024 20:34:57 +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 20:34:57 +0200 Original-Received: (qmail 17731 invoked by uid 1000); 2 Jul 2024 18:34:57 -0000 Content-Disposition: inline In-Reply-To: <81b620d7-18a6-4c6e-8517-147a411ee882@gutov.dev> 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:321198 Archived-At: Hello, Dmitry. On Tue, Jul 02, 2024 at 21:03:43 +0300, Dmitry Gutov wrote: > On 02/07/2024 09:50, Juri Linkov wrote: > >>> 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? > >> +@kindex C-x 4 LEFT > >> +@kindex C-x 4 RIGHT > >> +@kindex C-x 4 UP > >> +@kindex C-x 4 DOWN > > I can't believe someone might want to use such long key sequences > > for one of the most frequent actions. It's even longer than > > 'C-x o' it's supposed to improve. I think there are no better keys > > for switching windows than arrows with a modifier. > I'm going to ask a dangerous question: do people use the existing > bindings for "C-x " and "C-x "? That's next-buffer and previous-buffer. No, I don't use them, mainly through not being aware of them. They could come in handy, though, when looking at N buffers in M windows, with M < N. I've been in that position quite a lot in the last few months. Why do we not have next-buffer-other-window and previous-buffer-other-window? Why don't we have ....-other-frame? I think the likelihood that users have written such functions for themselves and bound them to C-x 4/5 / is high. This brings me back to my point about being careful about making default bindings. It would seem next/previous-buffer-other-window, whether yet existing or not, have a greater claim on C-x 4 / than the windmove functions... Also that we should preserve C-x 4 / for the -other-window versions of some future C-x / commands. -- Alan Mackenzie (Nuremberg, Germany).