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: Sat, 13 Feb 2021 11:24:24 +0300 Message-ID: References: <87czx5a947.fsf@posteo.net> <329d68a5ed1656b4427e@heytings.org> <87zh098lo4.fsf@posteo.net> <329d68a5ed26ba41356b@heytings.org> <87h7mhgyxj.fsf@posteo.net> <329d68a5ed0dcd10a78a@heytings.org> <87czx5gpuj.fsf@posteo.net> <329d68a5ed4f4c7e84fb@heytings.org> <877dndgnhp.fsf@posteo.net> <329d68a5edfafadfe7cd@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="30409"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: Philip Kaludercic , 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 Sat Feb 13 09:29:00 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 1lAqIV-0007n0-Uc for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 13 Feb 2021 09:29:00 +0100 Original-Received: from localhost ([::1]:38110 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAqIU-0004ta-W5 for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 13 Feb 2021 03:28:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60530) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAqHm-0004tE-9d for help-gnu-emacs@gnu.org; Sat, 13 Feb 2021 03:28:14 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:59587) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAqHj-0003j6-NH for help-gnu-emacs@gnu.org; Sat, 13 Feb 2021 03:28:13 -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 000000000001E07B.0000000060278D95.00005BEE; Sat, 13 Feb 2021 01:28:04 -0700 Mail-Followup-To: Gregory Heytings , Philip Kaludercic , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <329d68a5edfafadfe7cd@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:127913 Archived-At: * Gregory Heytings [2021-02-13 00:49]: > And that doesn't solve the problem that 26 letter keys is a small number. > Yes, you can also use capital letters, and yes, you can put keymaps on these > 26 letters instead of single commands. IMO, that can't work as a long-term > solution; if it were, it would already be used, and the fact is that it > isn't, and that third-party packages prefer to use, or recommend to use, > keys that are not yet bound by Emacs. I see that combination already as huge one. I have my own packages bound to prefix keys and I do use capital letters too like small letter "l" in combination {C-c p l} I use to list people of certain group but {C-c p L} I use to list all the recently entered people in the database. Additionally to letters there are also various symbols, so there are a lot of combinations. Then we have: C-c LETTER (26 or more on international keyboards) x 2 (for capital letters) + number of symbols than that is maybe approximately 60-70 keys, and if some of keys are used as prefixes then we have 60 x 60 = 3600 possible keys roughly estimated. Then if we add Super key to it, it becomes more than 7000 possible keys, if not 7500 or more. Isn't that quite enough? Then if third party package defines keys they could just say to user "bind the map to any key you wish, we recommend C-c g" and the 40 commands used by third party package may be invoked by using C-c g LETTER/SYMBOL > Again: this, to reserve prefix key(s) for third-party packages, and only > this, is what the proposal is about. I think the proposal should say that reservation is meant for global bindings by third party packages. After consideration of many details I think that proposal is there to solve specific problem, but that problem may not be solved anyway and there are already various solutions to that problem even without the proposal. For example Magit did bind some keys and it works. There is no problem. Those users who wish to change some keys they can adapt little or replace some keys. But I don't think that proposal comes from Magit developers, does it? So the solutions to that problem are already in existence how I understand it. Suggesting a prefix key to be bound by user on some of users' reserved key is another solution as well. In my opinion the number of possible keys is already over 7000, probably even 10000 and more. Emacs would not so quickly use those keys for itself. For example none of Super key bindings is used by Emacs. That makes alone possibly 7000-10000 possible combinations. Reserving a key or keys by Emacs for general unknown third party package would also require that there is some kind of a database of reserved keys for various third party packages and such does not exist. Similarly for /package or slash package enthusiasts which I am one of them, there exists database of allocated package names: https://cr.yp.to/slashpackage/list.html but in Emacs we do not have the database of allocated key bindings for third party packages. So third party packages may do anyway what they wish and want. Reserving the key does not solve the randomity of plethora of combinations that third party packages can invent and do, they may collide with each other, they may use unused or used keys, combinations are too many. Those who did understand conventions they did their best and already provided solutions. The solution should come from third party package in consensus with the user who does the installation. Solution to third party packages should not come from Emacs, as that is what they are: third parties. Then if we reserve let us say M-z for third party packages, then one package will say I wish {M-z m} for command X, other package will say they wish {M-z m} or command Y, so there is no benefit, again we have numerous possible imaginary problems where there are no practical problems. Solution to the problem of how third parties want to function cannot possibly come from Emacs. Additionally third parties are not controlled by Emacs development, they have zero obligation to listen or to comply to it. Those who do listen and comply will not have the database of allocated key bindings and will have possible collision with other third party packages. After the reservation of the key for third party package, then who is to make the effort to inform all the thousands of developers of the reservation? Reservation for packages requires informing people of those reservations. Why would they comply? Emacs development is not dictating how third parties should set their bindings. We have seen here that users set their key bindings just how they wish, somebody may remove C-o completely for something else, somebody protests against this. The pattern of key bindings by users is capricious. That is what we can learn from discussion and the same capricious pattern is there with third party packages. Who would guarantee that third party packages would now use those reserved keys and not set globally anyway otherwise reserved keys? All for thinking. Jean