From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Francis Belliveau Newsgroups: gmane.emacs.help Subject: Re: PROPOSAL: Repurpose one key and reserve it for third-party packages Date: Mon, 8 Feb 2021 17:01:50 -0500 Message-ID: <257D3F14-BC7F-4C72-ABB0-8178D501BCE5@comcast.net> References: <7e12c1c3c1aae58993e2@heytings.org> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19824"; mail-complaints-to="usenet@ciao.gmane.io" Cc: help-gnu-emacs@gnu.org To: Gregory Heytings Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 09 00:59:22 2021 Return-path: Envelope-to: geh-help-gnu-emacs@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 1l9GR7-00053L-T2 for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 09 Feb 2021 00:59:22 +0100 Original-Received: from localhost ([::1]:45794 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9GR6-0000iY-Uk for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 08 Feb 2021 18:59:20 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47894) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9Eba-0008Ug-Aw for help-gnu-emacs@gnu.org; Mon, 08 Feb 2021 17:02:06 -0500 Original-Received: from resqmta-ch2-11v.sys.comcast.net ([2001:558:fe21:29:69:252:207:43]:57934) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9EbX-0006Nj-70 for help-gnu-emacs@gnu.org; Mon, 08 Feb 2021 17:02:01 -0500 Original-Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id 9EOWlTnkAjtOr9EbTlrv2A; Mon, 08 Feb 2021 22:01:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1612821715; bh=MyMWB16GQwtUOzFPDa6Y9ncuHfxpmzPpP8CJhK57nE4=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=qJ58KoOh5Rs6J7GH3jx5fhTi96GuTRSrbhF0E94IT7IsS5WSmxsOmqTWViz+xKVqH VggtPFmfZ36GhUmqI4UhBSqB3KR0S4iEM+EDKVDx2CTcgjOjE6SdvmrD5L8wJJ/tIx 7ADOCG3R86OzxF5kQQ9BAITCaAnK6wSW0U/TpIG5awQ52JQzRGrM1/lg/virZL1kqy bWHLr1Zg3VhTU+5dkMiIurE+usmuFM3tCOsnsTEWMvCPEuOrGUPOM86DRZkK8NnXMQ Zjs6UZP196b175Rgmz+iRXwzMnfmO/QGMmjV398jiokDZBkSPuFsZp27pQOv4xrIH4 PWYOjlukA6/nw== Original-Received: from [192.168.1.105] ([73.119.168.97]) by resomta-ch2-06v.sys.comcast.net with ESMTPSA id 9EbPlnG2pRxAF9EbQlWNVL; Mon, 08 Feb 2021 22:01:54 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduledrheefgdduheejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhephfhrrghntghishcuuegvlhhlihhvvggruhcuoehfrdgsvghllhhivhgvrghusegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpedtkeegfffgffdtgeduveeuffegueduleffjefhudevjeehgeekjeevhefhjeettdenucfkphepjeefrdduudelrdduieekrdeljeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddruddthegnpdhinhgvthepjeefrdduudelrdduieekrdeljedpmhgrihhlfhhrohhmpehfrdgsvghllhhivhgvrghusegtohhmtggrshhtrdhnvghtpdhrtghpthhtohepghhrvghgohhrhieshhgvhihtihhnghhsrdhorhhgpdhrtghpthhtohephhgvlhhpqdhgnhhuqdgvmhgrtghssehgnhhu rdhorhhg X-Xfinity-VMeta: sc=-100.00;st=legit In-Reply-To: <7e12c1c3c1aae58993e2@heytings.org> X-Mailer: Apple Mail (2.3654.20.0.2.21) Received-SPF: pass client-ip=2001:558:fe21:29:69:252:207:43; envelope-from=f.belliveau@comcast.net; helo=resqmta-ch2-11v.sys.comcast.net 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:127668 Archived-At: I vote against the removal of the current C-o functionality. I would = not want to use two keystrokes where I currently use only one. I expect that those that use emacs in terminal windows will also find = the remapping of C-z a problem, but that is actually never done in the = middle of file modification so I wold expect it to be less of a problem. Overall, I expect that if a package has a number of functions it wishes = to map, if should have a method that installs itself into a keymap of = user choosing. Most packages do not need more than I few keys, although = I have one that implements 15. I put that behind M-o. I do not know elisp enough to know if one can determine if a keystroke = is a prefix key or not, but two functions could be implemented: bind-keymap-to() and add-bindings-to-keymap() with appropriate prefixes = and arguments of course. A package that implements these two would allow a used to decide say: bind-keymap-to('C-o') and that would unbind C-o and convert it into = a prefix key with empty keymap if it is not already a prefix key, then = call the package's add-bindings-to-keymap('C-o'). Otherwise, if a user want to rebind a key that they already know is a = prefix key, the can just call the "add-bindings" function. Please do not tell me the syntax above is wrong since I expect that is = it. I only mean all that as a pseudo-code example. The majority of the Rationale below is good, but it does not take into = account the needs ot those who have decades of muscle-memory for = high-speed editing that would get disrupted. A command like "suspend" = would never be used in an editing sequence, since it interrupts the edit = session. M-z and M-o are not keystrokes that I use, but I expect that = those who do would have the same complaint with the remapping of = "zap-to-char" thart I have with "open-line". I cannot even guess why I = would want a keystroke for "facemenu-keymap", but it sounds to me like = it is already a prefix key. BTW, your 25-years of history statement is inaccurate since I am sure = that I have been using C-o since before 1990. > On Feb 8, 2021, at 05:02, Gregory Heytings = wrote: >=20 >=20 > [S Boucher apparently intended to reply to the following proposal sent = on emacs-devel.] >=20 > =3DProposal=3D >=20 > It is proposed to repurpose one key, and to reserve it in the key = binding conventions for third-party packages. The keys that could be = reserved for that purpose are: >=20 > Option 1. C-z, with a single exception: "C-z C-z" would be bound to = "suspend-frame" >=20 > Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound = to "suspend-frame", and "M-z M-z" to "zap-to-char" >=20 > Option 3. C-o, with a single exception: "C-o C-o" would be bound to = "open-line" >=20 > Option 4. C-o and M-o, with two exceptions: "C-o C-o" would be bound = to "open-line", and "M-o M-o" to "facemenu-keymap" >=20 > =3DRationale=3D >=20 > The current key binding conventions (see `(elisp) Key Binding = Conventions') reserve keys for users, for major modes and for minor = modes, but not for third-party packages [1]. >=20 > When such packages need to bind a command to a key, they can (1) = either suggest users to bind it to a key reserved for users (for = example, org-mode suggests to globally bind "C-c c" to org-capture), or = (2) bind it to a key currently unused by Emacs (for example, Magit binds = "C-x g" to magit-status in buffers visiting a file in a Git repository). >=20 > Neither of these solutions are optimal: (1) requires an explicit = configuration by the user, something which might confuse newcomers, and = which other users might not want to do because they already use the keys = reserved for users for other purposes, and (2) might conflict with the = evolution of Emacs when one or more commands are bound to a yet unused = key. >=20 > Reserving one key for third-party packages solves the above problems: = third-party packages can automatically bind a few keys in that reserved = area, without conflicting with keys reserved for users and without = conflicting with future Emacs evolutions. >=20 > =3DLimit=3D >=20 > Conflicts are still possible, when two or more packages bind the same = keys. These are, however, conflicts between packages, not between a = package and Emacs, or between a package and users' personal = configurations. >=20 > Such conflicts are also less likely for typical users, who install a = few packages each binding a few keys. >=20 > Finally, such conflicts can be dealt with without confusing users too = much: a package could automatically choose fallback key bindings when = the preferred ones are already used by another package, and/or issue a = warning to the user that they need to bind its commands manually. >=20 > =3DNote=3D >=20 > [1] These conventions were written 25 years ago, at a time when there = were far fewer third-party packages, and have not changed substantially = since them. >=20