From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.help Subject: Re: PROPOSAL: Repurpose one key and reserve it for third-party packages Date: Tue, 9 Feb 2021 09:31:31 +0300 Message-ID: References: <7e12c1c3c1aae58993e2@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32827"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) 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 07:36:29 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 1l9MdQ-0008Qp-QJ for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 09 Feb 2021 07:36:28 +0100 Original-Received: from localhost ([::1]:60548 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9MdP-0002eA-TC for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 09 Feb 2021 01:36:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37290) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9McV-0002dq-By for help-gnu-emacs@gnu.org; Tue, 09 Feb 2021 01:35:31 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:60175) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9McT-0007Rm-3E for help-gnu-emacs@gnu.org; Tue, 09 Feb 2021 01:35:31 -0500 Original-Received: from localhost ([::ffff:41.202.241.3]) (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000001E079.0000000060222D0E.00007258; Mon, 08 Feb 2021 23:34:53 -0700 Mail-Followup-To: Gregory Heytings , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <7e12c1c3c1aae58993e2@heytings.org> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com 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: 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:127680 Archived-At: * Gregory Heytings [2021-02-08 19:38]: > > [S Boucher apparently intended to reply to the following proposal sent on > emacs-devel.] > > =Proposal= > > 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: > > Option 1. C-z, with a single exception: "C-z C-z" would be bound to > "suspend-frame" Please consider that C-z is internationally vague and could cause some inconveniences, as "z" is not always on the place where one think it should be, it is often replaced with "y" on international keyboards. It breaks some muscle memories. I would not change C-z on terminal to nothing else but the long term historical default. > Option 3. C-o, with a single exception: "C-o C-o" would be bound to > "open-line" That would be so detrimental to remove C-o to do something else but `open-line' function. > 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]. In my understanding those third party packages usually define major or minor modes so the reservation of keys for third party packages is thus already supported that way. There are many commands and it may be better to tell third party packages to advise user how to bind keys or to propose to users the key bindings and how it would otherwise change existing key bindings. That is not so hard really. It could be just one screen with questions when user invokes the package first time. For example, Org agenda keybindings was proposed to me, now I do not know by which party, but I got used to their proposal. Even though I do not use agenda, it is bound on {C-c a}. The proposal was in accordance with the key binding convention. So it looks just fine and clear. So I think there is no need to reserve more keys for third party packages. Finally, keys are limited. > 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). That is good way to go. > 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. Yes, I would like myself that Emacs is optimal and very ready for newcomers, but it is not. "Emacs is the advanced, extensible, customizable, self-documenting editor." Emacs is advanced, thus not a simple editor. It is for beginners and advanced users, as advanced users would never become advanced if they were never beginners. But those beginners would never become advanced if they are spared of configuring Emacs. Let us not forget that many Emacs Lisp programmers became such due to fiddling with their configurations in the first place. That is positive impact, not a negative impact. We want people to learn programming. Programming is confusing when one enters into the subject. And so is the subject of computing and any other subject. That is the learning path. That is why I think that (1) and (2) is not not optimal, it is state of Emacs. Developers and contributors are making it newcomer friendly, and that is never ending process and never completed, and never will be. That is the state of Emacs. These conversations also show that there will never be an optimal state, there can be some consensus or approval by some users, but never an optimal state. > 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. There are more than one keys reserved already in the manner you described such as those reserved for users can be proposed and used by third party packages, including those for minor and major modes, they can be used by third party packages. Solution is just there. Reserving key for third party packages sounds limiting to me. They may have different preference than just one key. Recently I have learned how to define the prefix command: (define-prefix-command 'cf-map) (global-set-key (kbd "s-p") 'cf-map) ;; By changing this one, one can ;; move all subsequent keys to ;; different prefix (define-key cf-map "F" #'cf-find-files-of-person) (define-key cf-map "L" #'cf-tabulated-last-people) (define-key cf-map "l" #'cf-tabulated-people-of-account) (define-key cf-map "a" #'cf-account-helm) (define-key cf-map "d" #'cf-people-by-description) (define-key cf-map "f" #'cf-follow-up) (define-key cf-map "i" #'cf-people-by-interactions) (define-key cf-map "m" #'cf-people-by-mark-new) (define-key cf-map "n" #'cf-create-contact) In my opinion that is great way of defining keys for third party packages. They could define the full key bindings list and let the user decide on the prefix key. They could propose some prefix key. It is one line in the configuration. It is something like: (global-set-key (kbd "s-p") 'cf-map) Or (global-set-key (kbd "C-c") 'cf-map) or similar. As not to confuse users programmer may invoke a wizard question: "It is detected that you could use following prefix keys for third party package: s-p (Super/Hyper key may have Windows logo on Windows keyboards) C-. C-, which one do you like to use as prefix key for this third party package? Some question as above could help users quickly decide on a prefix and the line could be automatically inserted into the configuratio file. Otherwise, simple explanation and advise to user how to place the configuration line is also minimizing any confusions. > 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. Good idea. So those packages could even now automatically do that as there are many keys available. In general I just think that more marketing is required to package authors on how to prepare key bindings and let users decide on it. Maybe one could make a package that changes the prefix key or various packages or the package that could "see" which packages are used and which of them need positioning of their prefix keys. Then such package could ask user with proposal: - C-c bind prefix key for Org functions - C-, bind prefix for Magit functions Approve or change above y/n? Jean