From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Proposal: new default bindings for winner and windmove Date: Tue, 02 Jul 2024 07:28:31 +0000 Message-ID: <87sews5k2o.fsf@posteo.net> References: <87cynw7omw.fsf@dancol.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24167"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Alan Mackenzie , Dmitry Gutov , 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 09:29:39 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 1sOXxL-00062x-99 for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Jul 2024 09:29:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOXwR-0004Ut-Dr; Tue, 02 Jul 2024 03:28:43 -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 1sOXwP-0004UZ-3S for emacs-devel@gnu.org; Tue, 02 Jul 2024 03:28:41 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sOXwM-0007lr-HQ for emacs-devel@gnu.org; Tue, 02 Jul 2024 03:28:40 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E381E24002B for ; Tue, 2 Jul 2024 09:28:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1719905314; bh=0xX6QmlGC896sriLxzS/P4TuToa17UUkhjJvSWWA7TI=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=mKISSuCVynWJ7vXnkzHBjpCMNeLiykxIuFKDgxaITHQLmO2hbOVaHialP73ILjqAA sK4bNXkFKkdk0n7j82TDh12r4Clysm1t/Q6w6Q+PtxHd1DIvlz0FU8FcCGIfnXGUX+ qzBIYz1ZQXL3Fj4I23xaGshzxxQGnuAtuG8jfKk6shN083Fig9n1vWbvJSTeD9t1OK XX7ej07jgQEcC987qLZv/9WvIQcoasAGaCIeojpsTklWmeJhcko6qsWzwCON7e5d7K xm2I1hiPZSdjZPO9gsZKjAgnEHOOCame9i62PXRoQxyVzUJgbJuA+LkkA17o7lzNW4 bLJxfma+S2SLQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WCvf80KVGz9rxQ; Tue, 2 Jul 2024 09:28:32 +0200 (CEST) In-Reply-To: <87cynw7omw.fsf@dancol.org> (Daniel Colascione's message of "Mon, 01 Jul 2024 18:07:03 -0400") OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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:321106 Archived-At: Daniel Colascione writes: > [Re-sending: accidentally sent narrow reply] > > Alan Mackenzie writes: >> Hello, Dmitry. >> >> On Mon, Jul 01, 2024 at 14:25:51 +0300, Dmitry Gutov wrote: >>> Hi Alan, >> >>> On 01/07/2024 13:07, Alan Mackenzie wrote: >>> > 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. >> >>> People screaming "backward compatibility" for each and every reason can >>> indeed be a problem. >> >> Yes, but it's a difficult problem. I would be screaming if somebody >> suggested removing the bindings C-o or C-M-o, for example. I use these >> all the time. But if I were the only user of them, it would be >> difficult to argue for their retention in the default key map. > > I still think we need to find a better binding for C-o, FWIW. > I recognize I'm in the minority on this position though, but still, I > think I've used C-o maybe once or twice ever. > > What do you use it for? My hands rewrite RET C-b to a C-o (especially when repeated). I know I use it frequently, but I cannot think of a nice example. That is part of the issue: These key bindings constitute a mental language of a lot of Emacs users. Removing, rebinding, changing these is disruptive, just as it would be disruptive to wear mittens all day long or not being allowed to use words that end in "u". When writing and editing, I don't directly think in keybindings, but in text-manipulations, as I supposed others do too. On a less conscious level my fingers figure out the keybindings for everyday tasks, just as one doesn't think about moving every single finger when lifting up an object. Having to wake up from this automatism, due to a missing binding is disproportional annoying. (I am reminded of the ConTeXt vs LaTeX story, where ConTeXt might have been cleaner, but LaTeX preserved backwards compatibility. In the long run, this turned out to be an advantage for LaTeX, which despite its kluges, ended up being more reliable, especially when trying to re-typeset and old document. In the same sense, Emacs has these or those peculiar, arbitrary but fixed choices that make it a reliable foundation, for whatever changes happen around it (to operating systems, window managers, desktop environments, ...).) Also, in the case of C-o, there is a family of mnemonically related bindings, such as C-x C-o and C-c C-o and C-c M-o in comint buffers. >> On the other hand, C-x w h (highlight-regexp) already has a "more >> modern" binding M-s h r, so although I wouldn't be enthused about the >> removal of C-x w h, I wouldn't object to it either. > > What do you think of my previous keybindings-editions proposal? > >>> We should be able to change default key bindings more freely than we do now. >> >> Yes, but... Every time we do this, we're upsetting _sombody_'s work >> flow. I don't see any way of getting this increased freedom to change. > > I love how https://xkcd.com/1172/ is about us. > > > > -- Philip Kaludercic on peregrine