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 (why only one?) and reserve it for third-party packages Date: Sun, 14 Feb 2021 09:19:57 +0300 Message-ID: References: <87y2fsg5ve.fsf@posteo.net> <87mtw8fi6k.fsf@posteo.net> <87ft20f3ec.fsf@posteo.net> <8735xz67ye.fsf@posteo.net> <87mtw74j5h.fsf@posteo.net> 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="25957"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: Gregory Heytings , help-gnu-emacs@gnu.org To: Philip Kaludercic Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 14 07:22: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 1lBAn9-0006b5-S8 for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 14 Feb 2021 07:21:59 +0100 Original-Received: from localhost ([::1]:40674 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lBAn8-0006qg-UM for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 14 Feb 2021 01:21:58 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54176) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBAmS-0006qT-2Z for help-gnu-emacs@gnu.org; Sun, 14 Feb 2021 01:21:16 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:51479) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBAmP-0001Z6-63 for help-gnu-emacs@gnu.org; Sun, 14 Feb 2021 01:21:15 -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 000000000001E07B.000000006028C155.00005913; Sat, 13 Feb 2021 23:21:09 -0700 Mail-Followup-To: Philip Kaludercic , Gregory Heytings , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <87mtw74j5h.fsf@posteo.net> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: 16 X-Spam_score: 1.6 X-Spam_bar: + X-Spam_report: (1.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_DOTEDU=1.999 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:127999 Archived-At: * Philip Kaludercic [2021-02-14 02:57]: > Jean Louis writes: > > > * Gregory Heytings [2021-02-14 00:19]: > >> > > > Sorry for protracting the conversation, I just think the > >> > > > interpretation of the guideline is important. > >> > > > >> > > Not for the proposal itself. > >> > > >> > Well yes, because if packages may bind to C-c *with* the consent of > >> > users, the need for a special package map decreases. > >> > > >> > >> As I said, IMO it does not, it can't work as a long-term solution, 26 > >> letters is simply not enough. Anyway, neither I nor you can decide what the > >> "correct" understanding of that guideline is, so I suggest we stop arguing. > >> A proposal has been made, we'll see what the maintainers do with it. > > > > C-c a - can be bound to single command > > > > C-c a - can become prefix key for other 54 various commands like 26 > > letters plus upper case letters = 52 plus 10 numbers = 62 + 32 > > symbols = 94 various commands > > C-c a a - can become as well prefix key for 94 various commands > > C-c b a - can become as well prefix key for 94 various commands > > etc. > > > > It can work as long term solution. > > This would only work, if you insist that packages only bind C-c LETTER > to a map, and not another package, which also only works if the user > doesn't decide to bind C-c LETTER to a command. Thank you. Here is what I promote: - packages should not bind globally keys without asking user. When user is asked, user has got the control and that is in the spirit of free software. In that case any key can be decided by user to be bound to package functions. - I don't say packages should bind C-c keys to anything without asking user. By asking user, user gets control and can decide which keys to be bound to which functions. - Yes, I think it is much better to bind C-c LETTER to a map instead of binding one key to one function. - No, don't understand yet the proposal in this subject to "re-purpose one key and reserve it for third party packages". How would that look like? Does that mean for example to re-purpoe C-x for third party packages so that they do something like: C-x a - third-party-package-function-1 C-x b - third-party-package-function-2 C-x c - third-party-package-function-3 Is that meant with the proposal? In that case I find that proposal poor and detrimental. It would break one of the keys that Emacs was using and break the future for third party packages as those functions by using one key only, after the prefix key, would quickly be filled with third party packages. Instead, I have demonstrated that there are thousands and thousands of combinations if prefix keys are used. Additionally user can be asked by artificial intelligence which first prefix key to be used. In that sense the proposal for third party packages can be easily solved by the third party package: - Third party package shall prepare the key map. - Third party package shall ask the user to choose the prefix to help with customization. - That way third party package is asking user, if user wants, to re-purpose one key as prefix for that third party package and helps user to customize it. Problem is solved. Nothing to be solved on Emacs side. There was no real problem in the first place. There was hypothetical problem that was presented without good analysis. There are no package authors except of Drew, who asked for "some key" to be re-purposed for their specific package. There was no real problem in the first place as there was no contradictory forces against each other. Magit's decision to bind package on any key did not show any contradiction, packages anyway can re-purpose keys without asking Emacs development team. But people wish to solve the problem for imaginary package authors who did not even complain. The one who complained is Drew Adams and his key bindings were re-purposed for Emacs functions, but not in his favor. Adverse effect have taken place. > So I get that there might not be that many commands, but I'd dare to > claim that 52 keys are a fair number. Proposal to re-purpose one key for all third party packages is poor one. Especially if it is meant NOT to use prefix keys for key maps. > This is not a matter of computational power or memory, the needs are > not increasing exponentially over time. Right now, how it is, and due to convention, many packages will simply NOT set global key bindings but ask the user to set it. Yesterday I have done my M-x rgrep on local ~/.emacs.d/elpa and have found that as the case. I do not have many packages installed, just about 240+ and I guess that ratio of `global-set-key' continues for the rest of 5000 third party packages. Situation how it is now, NOT TO RE-PURPOSE ANY KEY for third party packages would continue with the same non-colliding pattern in the future. If we DO re-purpose one key for third party packages, new convention is introduced and it would lead to authors deciding to use that ONE KEY which was re-purposed (which was proposed as one key) and then among 5000 third party packages authors would be now inclined to actually start using `global-set-key' because the key for them was "reserved" and they would quickly (within 1-2 years) come into collision which does not exist now in reality as practical problem. > Keyboards have stayed more or less the same for over 70 years now > and mouses have rarely more than three buttons. That can change drastically as innovation is developing. Keyboards did not quite stay more or less the same, obviously we miss some modifier keys. On about 50% of computers today keyboards completely disappeared without us, you, people noticing it, those are small fully featured computers that we call mobile devices. Most of them do not have physical keyboards, so we cannot say it stayed the same, it did not. Engelbart did not introduce just a mouse, there was a chordset with 5 keys that I would find usable even today, but have nowhere to buy it. Reference: https://newatlas.com/engelbart-computer-mouse-and-other-innovations/17113/ That keyboard stayed the same is not a benefit, it is disadvantage. Now is 21st century, 2021, I have expected so much more from the years 2001 unspoken of 2021 that we still use keyboards. I am expecting flat surface that may be customized anyhow, by using lighting where users may reinvent their own keys, where users need not even click the key, do not even need to type, they would just swing fingers in the air. We are back behind in time, in under-developed computing. On Android/Replicant/Lineage OS devices I have on some keyboards a possibility to "swipe" keys. I use often 2 mobile phones in the same time, I use only the left thumb to write things on one phone, the right thumb writes things on the other phone. Not quite in the same time, but that is how it may look like to onlooker. That is innovation that helps and drive speed. That desktop computer and notebooks still have fragile keyboards instead of cheaper sensors to track the movements is to me a a negative surprise of under-development and delay of innovation implementation. Reference: https://www.slideshare.net/01paresh01/keyboards-without-keys-and-boards https://www.academia.edu/7995378/Virtual_Keyboard_without_keys_and_board Keyboard layouts in general I find disturbing and old technology taken from typewriters. It, typewriter layouts, do not need and should not apply in computing of 21st century. Similarly like swiping on Android virtual keyboard I could just swipe in the air or touch those by light appearing letters in the air or touch the completions. On Android/LineageOS/Replicant, I can use one finger to control Emacs within Termux, I can send email with one finger only, the thumb, I can even use pinky if I do not hold the phone in the hand, but on the notebook or desktop computer I am bothered with whatever modifiers and key bindings beyond limits, and then we speak of reserving some of complicated key combinations for future. Well, there will be no future for keyboards, they will disappear and new combinations will open that may be so much simpler for users. When is that going to happen, I don't know, but soon, somewhere between 10-30 years in future. > Maybe it is just me, but it would surprise me if people would keep 52 > distinct commands in memory, which all have to be bound globally and are > easy to type. Not insisting on this though. I also think that mostly not. Yet some of users mentioned on the mailing lists to have bound their keys extensively. That is matter of application and users's demand. Number does not matter much. On my prefix currently I have bound 15 commands and not use them all, but I use more M-x commands which I feel I should bind to the same prefix. I have 48 various functions that I use frequently locate in the menu People, and menu WRS for Website Revision System. As menues are nicer ordered in categories I can easier choose the function that way, but should by feeling also bind some of those functions to the key map. About other 80 different functions are related to Hyperscope, the dynamic knowledge repository and maybe some 10-20 functions I should have globally bound to the prefix. I can remember what function does by its meaning but not necessarily how the function is literally named. For example I know that I can "Send note by email" to any person in the database and I can remember that "s m" sends it by email, but I forget that function name is `hyperscope-send-hyperlink-by-email'. I have not yet bound all the necessary keys, but I do have to as it speeds up my work. Using mouse pointer to go into the menu and find specific menu item takes me few moments more, using a key is faster. There are other users on mailing list who have bound their keys and filled a lot of the keys. Jean