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: Mon, 1 Jul 2024 10:07:27 +0000 Message-ID: References: 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="37600"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Daniel Colascione , emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 01 12:08:30 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 1sODxV-0009Yc-Kq for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Jul 2024 12:08:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sODwu-0006Hk-PZ; Mon, 01 Jul 2024 06:07:52 -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 1sODwt-0006HX-A2 for emacs-devel@gnu.org; Mon, 01 Jul 2024 06:07:51 -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 1sODwm-0001Jt-5f for emacs-devel@gnu.org; Mon, 01 Jul 2024 06:07:48 -0400 Original-Received: (qmail 36657 invoked by uid 3782); 1 Jul 2024 12:07:28 +0200 Original-Received: from muc.de (pd953a31c.dip0.t-ipconnect.de [217.83.163.28]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 01 Jul 2024 12:07:28 +0200 Original-Received: (qmail 5697 invoked by uid 1000); 1 Jul 2024 10:07:27 -0000 Content-Disposition: inline In-Reply-To: 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:321004 Archived-At: Hello, Stefan. On Sun, Jun 30, 2024 at 18:29:03 -0700, Stefan Kangas wrote: > Generally speaking, we provide an extensive set of keybindings. These > defaults ensure that Emacs is as usable as possible out-of-the-box. > There is of course room for reasonable people to agree or disagree to > what extent this or that keybinding is useful enough to provide > out-of-the-box; this is largely a matter of taste and how you use Emacs. > However, I'm not convinced by the argument that there is some > "keybinding real estate" that we are somehow occupying by adding _any_ > new defaults, since users can change keybindings relatively easily. > So there is no way around the need to consider each new proposal > individually. The above is true, but it misses the point. That point is that once the Emacs maintenance team has added a _default_ binding, that can never in the future be changed. People will scream "backward compatibility" until the heat death of the universe. In that sense, "keybinding real estate" very much is a real issue - we can only add so many default key bindings, and once added they are difficult to change or to remove. > Now, it is clear that there is a need for users to navigate between > windows. The need for even more specialized commands (e.g. windmove, > ace-window) is arguably bigger today than it used to be. Users will > routinely have huge monitors where they can have a large number of > windows visible at the same time. What served users in 1995 will not > necessarily be enough for the needs of users today. This is one of these user dependant things. For some users, sophisticated window changing commands will be essential for using Emacs at all, others simply won't need them, and there will be few users in between. > In my view, having considered this discussion in full, the benefits of > adding these key bindings, favored by several developers, therefore > outweigh the perceived drawbacks. That "perceived" there is a mistake. The drawbacks are real. At the very least, such usage is liable to provoke a long, withering post from Drew Adams. ;-) > - The proposal is to add global bindings, which AFAIU means that they > will not affect people that are binding these keys to something else > (whether globally or in specific modes). > - People that do not like these keys do not need to use them, or they > can unbind them, or rebind them to something else. As already said, those people don't include the Emacs maintainers when considering default key bindings. > - The relevant windmove commands are already autoloaded. > - There is no need to deprecate anything to add these bindings. > 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). I think I would agree with the somebody else that suggested enabling these keys by a minor mode. -- Alan Mackenzie (Nuremberg, Germany).