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: [External] : Re: not good proposal: "C-z " reserved for users Date: Sun, 14 Feb 2021 00:17:39 +0300 Message-ID: References: <7eccb0b5-8371-e34a-3371-09b75e1a385a@yandex.ru> <877dnc4dwf.fsf@robertthorpeconsulting.com> 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="23776"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: "joostkremers@fastmail.fm" , "help-gnu-emacs@gnu.org" , Robert Thorpe , Dmitry Gutov To: Drew Adams Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 13 22:18:57 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 1lB2Jc-00065Y-Lx for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 13 Feb 2021 22:18:56 +0100 Original-Received: from localhost ([::1]:43812 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lB2Jb-0008Nt-P1 for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 13 Feb 2021 16:18:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47356) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lB2It-0008L7-Cb for help-gnu-emacs@gnu.org; Sat, 13 Feb 2021 16:18:11 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:35967) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lB2Iq-0007hP-VT for help-gnu-emacs@gnu.org; Sat, 13 Feb 2021 16:18:11 -0500 Original-Received: from localhost ([::ffff:197.157.0.47]) (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000001DFF5.000000006028420D.00002F64; Sat, 13 Feb 2021 14:18:05 -0700 Mail-Followup-To: Drew Adams , Robert Thorpe , Dmitry Gutov , "joostkremers@fastmail.fm" , "help-gnu-emacs@gnu.org" Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -3 X-Spam_score: -0.4 X-Spam_bar: / X-Spam_report: (-0.4 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no 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:127974 Archived-At: * Drew Adams [2021-02-13 23:49]: > To be clear, my understanding, from following bug > and emacs-devel threads, is as follows. Anyone > can correct me if I'm mistaken in any way. > > 1. `C-x p' was recently grabbed as a prefix key > for Project (by Dmitry, in fact) - over my pleas > and arguments not to. That was maybe 8 months ago? > > Bookmark+ had, for many years, lots and lots of > keys on that prefix key. The only arguments by > Dmitry in favor of grabbing that key for Project > were, in effect, (a) we want to do it and (b) we > don't need to care what Bookmark+ has been using. > OK. Basically, the attempt to reserve some keys which were already in use by third party packages did not work well and you participate in mailing lists. Does Magit author participate too? As now it looks like much attention is given to Magit but to me it looks like none of them who are authors requested any favor from Emacs to reserve it for them. I have just done M-x rgrep and found that many installed packages simply suggest global key bindings, just few of them really bind it. > 4. I'll mention too that for Bookmark+ when I > changed from `C-x p' to `C-x x' I added a user > option for which key to use. So users can deal > with the new conflict themselves, if I don't > end up trying yet another key as the default. That looks good as solution. Packages rather make the key maps and then simple function could suggest few of key bindings and detect which one is already bound to which keys and then suggest the menu or choice where to place the prefix key. Function could accept a list of various suggested prefix keys and then verify each key if it is bound to something, and present the listing let us say from 1 to 10 where keys are presented and displayed as being bound. User can then choose to unbind specific key or use those free keys as prefix for the package. If series of keys is not enough at some point of time, new versions of the package could employ newer or updated list. (global-set-key-prefix-by-choice '("C-c p" "C-c o" "C-c j" "C-x x" "C-x /" "M-z")) Then it could be presented as: 1. C-c p - free as prefix key, press [1] to select 2. C-c o - free as prefix key, press [2] to select 3. C-c j - free as prefix key, press [3] to select 4. C-x x - bound to `some-other-function', press [4] to select 5. C-x / - bound to `one-more-function', press [5] to select 6. M-z - bound to `zap-to-chat', press [6] to select Are you sure? Yes? If you wish to customize the prefix key again for this package, run M-x customize-prefix-for-package-X > I proposed one possible solution - a _moratorium_ > by Emacs from grabbing more keys by default. Look > up the word "moratorium", if you aren't familiar > with it. * Overview of noun moratorium The noun moratorium has 2 senses (no senses from tagged texts) 1. moratorium -- (a legally authorized postponement before some obligation must be discharged) 2. moratorium -- (suspension of an ongoing activity) So you suggest suspension of grabbing more keys? That sounds good idea to me as well. There is no urgent need for that. That is why there are reserved C-c keys, users can bind those new functions. If there is some important function to be bound than that could or should be solved with discussion. > If you like, you can consider my proposal to be: > Let's at least STOP now from binding any more keys > by default, while we entertain discussion for other > possible solutions. And as long as no adequate > solution, preferably somewhat consensual, is found, > Emacs just shouldn't bind more keys. It can > repurpose keys that are already bound by default, > but it should stay away from binding new ones. Maybe it will work the other way around, you start proposing to bind more keys by default, maybe that can work better? I am not joking too much. When pushing too much one thing in public space there is effect that people may want the other thing (not being pushed one). Start pushing the opposite, maybe that suddenly start working and keys stop being bound. > I really would like to see us, FIRST, stop the > bleeding by agreeing that Emacs should stop binding > default keys while we figure things out and, SECOND, > start discussing solutions in parallel, with less > urgency, carefully. And that discussion can, yes, > consider particular _existing_ key bindings and > possibilities of refactoring Emacs default key > bindings. > > But the first step should be to agree to stop the > bleeding: "Emacs: hands-off new default keys, please." If I have understood it well, maybe I may be mistaken, but the discussion to reserve the key yieled intentionall or not intentionally with proposals to bind range of new keys. I am not sure if implemented already, but I have seen the list. That is why, how about stop pushing to bind keys and demand more bindings, maybe that causes less bindings? Jean