From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: Emacs default key bindings [was: Opening Up More Keymaps Re: Standardizing more key bindings?] Date: Fri, 2 Oct 2020 21:24:02 +0200 Message-ID: <20201002192402.6oldqiknglyf54xl@Ergus> References: <364afb35-1cf9-4bd8-a34d-370dc428f950@default> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36721"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "T.V Raman" , Thibaut Verron , emacs-devel To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 02 21:25:43 2020 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 1kOQgY-0009RE-W6 for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Oct 2020 21:25:43 +0200 Original-Received: from localhost ([::1]:52598 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kOQgY-0004RW-2i for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Oct 2020 15:25:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36636) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kOQfI-0003LC-JY for emacs-devel@gnu.org; Fri, 02 Oct 2020 15:24:25 -0400 Original-Received: from sonic315-14.consmr.mail.bf2.yahoo.com ([74.6.134.124]:32981) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kOQfD-00074f-O0 for emacs-devel@gnu.org; Fri, 02 Oct 2020 15:24:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1601666654; bh=CW/x0+zs5LjMTtN8KeFTGp8qL2UJTj5hm9TU5MsTpVA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=MqvkuYYLcdwbNZeovEGdr7boOnxFAmz1uoBl73fzFVsxacTrcl1ynR4Q6p4F353MkCffFRuPjF+O6JU4SBhG5kwPH/Vn9uYsBI4PQauNRCcrQI458eeLl1k12TVdCvf2Y4lhqC/aLXy8s+OzEup0Bo91LW71o+93tHQc1Cukxu6c8JP6k2w71+X1f19d8V0JvyQZqHidnwrE4SaZhqBt3AZiHVVjksTY9T3DddWlZQwwAny67LfjSfuiUex1GOg9moHu0/ra26Vbd+PJP0e9TtHZ5Ej5faTF2jKEI2Yb6FK8EJS9DN/M18aZIoPeIJiISpiaRQe1E2DN5DVgWxhX/A== X-YMail-OSG: l5IDNBEVM1m03.PeBXAKctfr.A.apjTo9.xvXIZrp2eVh0_3S0tHHSpF.ouSbBe 8gfwRx4Qa6fNMEcMp9NcoOmPdNwXyGIGQgE5_rA0xGBWhEViNHC51fb8TPUO9Vj9Ru0Hcjd46wss T.7nZr6RucYf0Zpia6K8NsSk9WlyyqUJ5IlCMZAbR0Kz3xIkMJYHxPCPNivPzVFriwPhFmi7WfQQ _OesSBwFlfvzMeTplDWB2cZUKzXXFgKVkveKTSYqNpFur7UdDoc9kigb7vfkK.NkPQgpFlPokVbX 0huJ6_MhuKidm9Q4ARYYswS4v_IIL7RHRVMOHpw0zn5CUaQgB_mAmki6TXNMEkv400odwTQqt2OM DhBoigObP2NHvBjvmB5YBkw76f4KUr6G37ylkruX481dW05V9j9A3_iRzMXtk0ij_BW_j7TRwbMb uRZ0Xevh9wUYWAOqdtJCyoNRSnWbm8wmfuPca7NPu37vRWHkUZL6oYF9cJXVLayGLU9qYFgcLEie pwtH2K8a_BAujZkFMfIureisgZQtI45ma6siACw0BPF1k6KTNJrirS37p25mlRgHjWTsI3AkqRAk 3B.QDm8pvJxJ2rcGfntRcG0WudyuYAs6Zj6T0cH3AWhD2IcCYJcuQoxpszoB3cbLVN5kPKm9Mozv KzWoggTwzOFDbY_SGEzU0U.BsX4Kyj2U6sb_E8vzlUDCF5IzlywUitrsvUZXqsYPLWW1YEEYDPZk 1d1cXIJVM4LcgZV8fVdRqfcyYyc5ceO9oIQoxkCIHxz5V5lsQdZKM_o7Ek4veL4VsR1IIdbqun18 lYQBt63Mgao6KPhvTNFcm686Yn4LpRQXmZJEUK1fAz Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Fri, 2 Oct 2020 19:24:14 +0000 Original-Received: by smtp408.mail.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7ac8998b25b4cb24bcc5742ac64412e2; Fri, 02 Oct 2020 19:24:12 +0000 (UTC) Content-Disposition: inline In-Reply-To: <364afb35-1cf9-4bd8-a34d-370dc428f950@default> X-Mailer: WebService/1.1.16718 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Received-SPF: pass client-ip=74.6.134.124; envelope-from=spacibba@aol.com; helo=sonic315-14.consmr.mail.bf2.yahoo.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/02 15:24:14 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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.23 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" Xref: news.gmane.io gmane.emacs.devel:256966 Archived-At: On Fri, Oct 02, 2020 at 11:14:48AM -0700, Drew Adams wrote: >> Perhaps it's time we opened up some additional keymaps... AFAIR: C-x is reserved for emacs internal use. C-c for users. So, external libraries should be ready to move from C-x * in favor of internal functionalities when needed. That's the deal. I don't think that many external features are more important than tabs or project commands in 2020. That's why they are in vanilla... And keeping some standard behaviors is very appreciated. It is not that we use more bindings, but that we have new functionalities all the time and some of them require new binding. While some of the oned with repeated bindings or less useful ones have to stay because otherwise long standing users create a storm here. (ex: F2) In general I agree with your idea about repeatable commands and bindings administrations... But you know that any change in that area is a bloody war. IMO the only possible solution for this (as with all defaults) is that Eli, Stefan, Lars and some other of the most implied maintainers (and with a deeper idea the current direction of the project) find an agreement between them and impose it in a less democratic way. Otherwise everyone will try to favor his own use cases, preferred tools and personal libraries... Otherwise we can make surveys with fix deadlines... but instead of making happy everyone this will probably make unhappy everyone. We could make an online form to vote... (like https://feathub.com/) In general it is better that emacs keep a reasonable standard behavior in some aspects otherwise it will be useless when working in different machines. > >Stayed out of this thread so far, hoping it would die >a healthy natural death. ;-) But here are my general >thoughts on the matter, FWIW. >___ > > >1. Keyboard keys are scarce. Many are already "taken" >by default by Emacs. (Yes, of course, users and >libraries can always _override_ any default bindings.) > >Some of the keys Emacs has "taken" could fruitfully >be revisited. > >Some are easily repeatable keys that are bound by >default to nonrepeatable commands, i.e., commands >that it makes no sense to hold the key down to repeat. > >Some are particularly easy/quick to type, and are >bound to commands that might not be used that often. > >Some were perhaps taken only because a key seemed to >be free at the time (often long ago), regardless of >how much a default binding was needed. (Recently F2 >has come up, as having been sacrificed for the >relatively unused/not-so-useful `2C-*' commands.) > >Any such keys could be looked at as keys we might >possibly want to "open up". > >(And no, I'm not saying that there aren't other >things to take into account when deciding on a >default key binding. Ease/speed of finger access, >for example.) > > >2. But what do we mean by "open up" or "free" a >default key binding? _I_ mean free it for use by >users and 3rd-party libraries. Have Emacs give it >up - let it go. > >I don't mean for Emacs to just bind it to something >different by default. That's _not_ freeing it up; >that's just rearranging. Rearranging can be useful >sometimes, but it doesn't help with the problem of >Emacs binding too many keys by default. > >Some here feel the pinch as Emacs not having enough >free keys to bind to more commands by default. I >feel the problem is the opposite: the pinch is on >users and 3rd-party libraries, and Emacs is doing >the pinching. Some here see a "free" key and want >to bind it by default, sometimes to their shiny >new command. > > >3. There's been a tendency recently to give Emacs >even more default key bindings. Two cases come >to mind, both in 2020: > >a. `C-x p' was taken by Emacs as a prefix key for > `project.el' commands. >b. `C-x t' was taken by Emacs as a prefix key for > `tabbar.el' commands. > >Maybe those deserve prefix keys (?). But you see >the tendency - less and less for users; more taken >by default bindings. > >That's 2 excellent prefix keys just removed, in >effect, from the user/3rd-party space. Poof! > >For example, in my code I've used `C-x p' and >`C-x 4 p' as prefix keys for Bookmark+ for over >10 years, but I changed them (`C-x x', `C-x 4 x') >in 2020 because of (a). > >(I have 86 key bindings organized onto those two >prefix keys - some on submaps: `C-x x a', >`C-x x b', `C-x x c', `C-x x t', `C-x x t +',...) > >And I've used `C-x t' as a suggested prefix key >for library DoReMi for 16 years. But I'll have to >change that in 2020 because of (b). > >I pointed this out here at the time. Response was, >in effect, "tough tiddlywinks". OK. > >https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00085.html > >The point is that instead of Emacs trying to reserve >_more_ keys as free for its users (without having to >override default bindings), the impetus here has >been to sacrifice ever more keys to default bindings. > > >4. When Emacs does decide to bind a key by default, >these two general guidelines (at least) should be >considered, IMO. (This applies to rearranging, as >well as to binding a previously free key.) > >1. Save naturally repeatable keys for commands that > can be repeated, i.e., commands that it makes > sense to be able to hold down a key to repeat. > >2. Save some keys for prefix keys, as opposed to > just sacrificing them for a single command. A > prefix key gives you a whole keyboard of > possibilities for a single key. Think of all > the mileage we get out of the prefix key `C-x'! > Of course, adding a prefix key makes a key > sequence longer, more complex. Tradeoff. > > >___________________ > >That point (#4) and the rest of this message >were part of a post of mine to help-gnu-emacs >on 9/23/2020, on pretty much this same topic: > >https://lists.gnu.org/archive/html/help-gnu-emacs/2020-09/msg00273.html > >I tend to define lots of keys for features I write, >and put them, by groups, on their own keymaps, and >then put those keymaps on prefix keys. > >Even if such a prefix key appears complicated or >slow, the fact of using a separate keymap means >that a user can easily put it on a different, >shorter key, or remap it to a more global keymap. > >Now imagine that keys aren't reserved by Emacs this >way - repeatable keys for repeatable commands, and >some keys available to be used as prefix keys. > >Imagine if Emacs just predefined `C-x' for a single >command (e.g. `cut'). _Zillions_ of keys bound now >under `C-x' would be sacrificed. > >At the very least, when a new key is decided to be >sacrificed by default (vanilla Emacs), it had better >be bound to a repeatable command, not one (such as >`cut') that it makes no sense to repeat. > >And even a repeatable key is a sacrifice - consider >if `C-x' were bound to, say, `forward-word'. >Repeatable, yes, but think of all the bindings now >under `C-x' that would be lost. > >Keyboard keys are precious - scarce. Too many have >already been sacrificed to default bindings, IMO. >Sure, any user or library can redefine any keys. >But once blessed as a default vanilla-Emacs key >binding, a key is, for practical purposes, kinda >off limits for a library. > >The point is that (1) it's easy to move a keymap >from one prefix key to another, and (2) there need >to be some prefix keys available to move maps to. > >Eventually, I imagine (hope) that some simple, >repeatable keys that have been assigned default >Emacs bindings for commands that aren't repeatable, >or that aren't super useful, or that don't really >need a single-key binding, will be recycled and >put to better use: for repeatable commands, as >prefix keys, or just unbound by default and left >available for libraries. > >No, I don't have particular suggestions, and no, >it's not urgent. > >But consider `M-!', for example. Sure, `!' is >mnemonic for shell. But `M-!' is repeatable >(just hold it down), and it makes no sense to >repeat `shell-command'. There are other default >key bindings like this - essentially wasted wrt >easy repetition. > >Some nonrepeatable commands bound to repeatable >keys should be replaced by repeatable versions. >I do that for `C-a' and `C-e', for example, so >they're similar to `C-n' and `C-p' (repeatable). >That kind of change is minimal - it's the least >we can do to make things a little saner. > >Take a look at `C-h b', and see which repeatable >keys are bound to nonrepeatable commands. Not >too many, but there are some. > >Even `C-w' is "wasted" on a nonrepeatable command. >Am I suggesting that `C-w' should not be bound by >default to `kill-region'? Not really. That's not >urgent, at least. But hey, keys are limited - the >keyboard's a small planet. ;-) > >And `beginning-of-buffer'. That nonrepeatable >command's bound by default to two repeatable keys, >`M-<' and `C-home'. Both mnemonic (good). But... >