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

[Jean Louis]

Maybe Emacs itself could have detection for a package that needs a
prefix, something like:

(need-prefix-key 'my-key-map) where `need-prefix-key' is the future
imaginary Emacs built-in function.

and then Emacs can on first invocation of the package function ask
user: This package requires a prefix key, please press some of the
keys like C-c and some letter or Super and some letter to choose
it. It could tell user that key is already bound and if user is unsure
or not.

User could also customize the option `ask-me-for-prefix-keys' if user
wish to be asked for those prefix keys.

That would be very hand solution, no package would need to set a key
globally, just make a map, and Emacs itself would be notified by the
package that package needs a prefix key. Emacs would then ask user for
prefix key if user has set the variable `ask-me-for-prefix-key'.

That solves the whole problem for many third party packages.

* Drew Adams <drew.adams@oracle.com> [2021-02-14 21:31]:
> (I haven't read all of your long message here.
> And I wouldn't have bothered to reply to it,
> if I hadn't noticed that you mention me in
> passing, and you did so inaccurately.)
> ___
> 
> > There are no package authors except of Drew, who
> > asked for "some key" to be re-purposed for their
> > specific package.
> 
> No, I never, ever, asked for any Emacs keys to
> be repurposed for any of my libraries.
> 
> I asked that keys that were _not_ yet bound by
> Emacs by default, continue to NOT be bound by
> Emacs by default.  That's all.  No repurposing
> - for my benefit or for any other reason.

Yes, that is what I meant despite inaccurate description.

> Not sure what you're referring to, but there is
> a very real problem of Emacs binding more and
> more keys by default - the set of keys still
> unbound by default is dwindling to extinction.

I understand your opinion but contrary to it, I found there are many
available key bindings, we mentioned here Super key, key prefixes or
maps, so it amounts in thousands. Keyboard will die sooner as physical
keyboard then the available key bindings.

> This is not a problem for _users_.  At least not
> directly.  Users can always bind any keys they
> like.  It's a problem for 3rd-party code (and
> thus indirectly for its users).  There need be
> no discussion about what users can do - they
> are welcome to do anything, and the conventions
> explicitly say so.

Even third parties are welcome to do anything.

What repercussion is there for third party if they actually break the
convention? Maybe such package would not be accepted in ELPA, but that
is about all. They are free to bind as they wish. But they don't and
follow the convention.

I have not found real conflict, like nobody said so far (that I have
spotted) that some key bindings seriously conflict with something
else. It is hypothetical problem, but not practical.

> It's not helpful for people here to simply
> ignore the discussion that's taken place (in
> emacs-devel and bug threads), and instead add
> repetition of Q&A and arguments.  Please read
> the discussion, so arguments aren't repeated
> here needlessly, wasting everyone's time and
> energy.

Maybe not. First one has to list the real problem, practical specific
problem. Let us solve that.

Put hypothetical problems on side, just disregard them. Recursive grep
in few thousands of MELPA packages has shown that almost none of them
binds C-c LETTER by default, there are those binding other keys by
default. But none of people complained.

Why reserve anything, if there is neither practical problem at hand to
be solved, neither almost none person to say I NEED THIS KEY X FOR
PACKAGE Y. One person I know is you that you need it, and your request
was ignored, I have not seen explanation why and how.

anx-api package:

(if anx-use-global-keybindings
    (progn
      (global-set-key (kbd "C-x C-a A") 'anx-authenticate)
      (global-set-key (kbd "C-x C-a a") 
'anx-get-user-authentication-credentials)
      (global-set-key (kbd "C-x C-a S") 'anx-switch-users)

pager-default-keybindings has some defaults set. Logical by name.

seethru package recommends some keyboards through a function, does not
bind by default (I guess).

cssh package bind C-= and C-M-=

move-text package has function to bind some keys

cycbuf package as well

better-defaults has some global bindings, logical to its purpose.

>From 2400+ packages the above shows that there are no conflicts so
far. Majority of packages recommend bindings to user to make it by
their own will.

So which real world, practical conflict is there at hand to be solved?

I would not say discussion is useless and that people have to follow
arguments carefully especially as we talk about key bindings that
practically do not affect users, nor cause problems.

> (That is, do that if you're really interested
> in the question/problem.  If you're not, then
> don't bother.

I have asked already before few days, what is the practical, specific,
real world problem to be solved? I do not see any after the analysis
of the discussion. I know your case, OK and I know you will find
solution to it. But you have not started discussion, you are proposing
constructive things.

Nevertheless, I see no real world problem.

I see hypothetical problems.

> But please don't just repeat questions or arguments here that have
> already been made in the more general discussion.)

I may mention, I am not a database that collects each piece of details
ever mentioned on all mailing lists and excludes those that have been
mentioned. That is life.

> > But people wish to solve the problem for
> > imaginary package authors who did not even
> > complain. The one who complained is Drew Adams
> 
> Actually, several people have argued that the
> problem exists.  You seem to be ignoring the
> general discussion and just imagining things.

If problem exist, then which real world problem is it?

Is it hypothetical problem with imaginary future packages?

Short analysis has shown that packages do not even bind keys, they
just recommend key bindings. That is the solution that existed before
and exists now. There is proposal that it may become little more
sensitive, program could recommend bindings by detecting which keys
are bound to what and let user just type or choose a new key for new
functions instead of advising users in the README or comment section.

So if packages do not bind keys by large, where is the real problem?

With "real problem" let us know the package name that bound some keys
and where it conflict with some other key, or where package author
does not have a solution to make package functional for the user.

> I spoke up then because that change affected
> me and users of my library directly.  I asked
> politely that they choose some other prefix
> key to grab for Project.  My request was
> rejected summarily, just because my code is
> 3rd-party.

That I have seen, it does not look nice. Did you solve the problem?

You can make a function that asks user on which key user wish to put a
prefix key. That would be solved with it. No need to dwell with
global-set-key, just let users decide themselves.

1. Press your preferred prefix key for this package

2. That key you have chosen is bound to `this-other-function', are you
   sure you wish to re-purpose the key for this package?

3. If no, press other prefix key and try again.

4. If yes, you may again customize the prefix key by invoking function
   "my-package-customize-prefix"

It should be that simple. Or do it as majority to advise user to set
bindings as they wish in the comments section.

Majority of packages do not bind keys for packages. That is simple
solution.

Package invocation like first time running of a function could detect
if a key has been defined as prefix and run the wizard to customize
the global prefix key. Some packages show that they have similar
functions, not really wizardry, but there are similar functions where
user invokes a function and package binds global keys.

Packages define various keys and let user make the prime decision. I
have seen with M-x rgrep that packages do similar to that.

This comes from anx-api package:

- it looks like if user defined `anx-use-global-keybindings' that it
  would automatically set some global keys.

(if anx-use-global-keybindings
    (progn
      (global-set-key (kbd "C-x C-a A") 'anx-authenticate)
      (global-set-key (kbd "C-x C-a a") 
'anx-get-user-authentication-credentials)
      (global-set-key (kbd "C-x C-a S") 'anx-switch-users)

but they will mostly suggest to users to use some of C-c combinations
in the comment section. I think that is old fashioned and that wizard
functions should do that work.

Jean