Re: PROPOSAL: Repurpose one key (why only one?) and reserve it for third-party packages

[Jean Louis]

* Philip Kaludercic <philipk@posteo.net> [2021-02-14 02:57]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Gregory Heytings <gregory@heytings.org> [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