Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 4455 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>>> Configuring a package, that provides a command as it's interface,
>>>> should be done by binding it to a key reserved for users. Just
>>>> like how configuring a minor mode is done by adding it to a hook
>>>> or a major mode by adding it to auto-mode-alist.
>>>
>>> What most users do is that they install third-party packages
>>> through their distro package manager, or through Elpa or Melpa, and
>>> they just expect / would like it to work.  That's what would happen
>>> when you install extension packages in most (if not all) other
>>> software (editors, browsers, ...): you don't have to manually
>>> fiddle with configuration files to make them work.
>>
>> If I install ffmpeg via apt on a Debian system, I expect it to work,
>> in the sense that I can invoke the command from the terminal
>> whenever I want to use it.  I don't think the analogy works for
>> browsers, since add-ons are usually filters or added to right-click
>> menus.
>>
>
> The point is that those "filters" or "right-click menus" are
> activated, you can use them right away, you don't have to manually
> edit, say, the ~/.config/chromium/init.js file beforehand.  If you had
> to do that, you would likely think it's a badly designed browser.

My point is that it makes sense for browsers, because the plug-in
framework has its boundaries, so "activation by default" is safe.

> All Emacs users are not programmers like you and me.

So what? Emacs is still the programmable text editor. I personally think
it is a great mistake that the default UX wants to hide computability,
and the fact that Emacs doesn't do that, is good. Free Software, on some
level is just about blurring the line between programmer (producer) and
user (consumer).

>> What might be interesting would be something like the gnu-elpa
>> package[0], or something that goes in the other direction, where a 
>> package can recommend a keybinding, hook, etc. and "automatically"
>> configure itself if the user agrees.
>>
>
> If there is no keymap reserved for package keybindings, packages
> simply cannot do that.  The point of the proposal is only to make that
> possible.

Why? Let's say a package includes a like like

        ;;;###autoload
        (add-to-list 'package-configuration-advertisement
                     '(avy (key "C-c z") avy-goto-word-1))

and package-install, when called interactively, checks if the key "C-c
z" has been bound, if the user is interested in what packages suggest,
etc.  and then suggests adding this keybinding. You can answer with
"yes", "no" or "other key", and it will automatically add it to your
init.el. No designated keyspace needed.

>> The problem I see is that key-bindings are usually user
>> configuration, and e.g. Magit *works* without them. I can do M-x
>> magit-status, right after installing it. No extra configuration
>> necessary. But if I want to have it easier, it's easy to add.
>>
>
> For you and me, yes.  For Emacs users in general, no.

How come? I don't know what you are referring to.

>> I think Ivy is a good example where this should *not* be the case,
>> because it changes the user-interface that can be confusing.
>>
>
> When you install a package whose purpose is to change the user
> interface, you expect it will change the user interface, don't you?
> When you install an ad-blocker in your browser, you expect it will
> block ads, don't you?

Again, the browser is a different situation. When I install a package, I
expect the package to be installed, that's it. I don't know if I want to
keep the package, I don't know how I want to use the package or
sometimes what it does. This kind of aggressive behaviour just makes
harder because you don't know what is going on. This is how you confuse
newcomers.

>> Packaging doesn't do configuration, and we shouldn't encourage this
>> misunderstanding.
>
> Some users, like you and me, don't want Emacs packages to
> automatically configure themselves, that's fine and will always be
> possible.  Other users, like me when I install a GIMP plugin, want
> that GIMP plugin to be automatically configured.  I would be very
> confused if I had to manually edit the ~/.config/GIMP/X.YZ/gimprc
> and/or ~/.config/GIMP/X.YZ/pluginrc before using a plugin.

Again, packages != plug-ins. We shouldn't dumb-down Emacs.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

[Why did you write your first mail off-list, your second one Cc'd to 
emacs-devel, and your third one Cc'd to help-gnu-emacs?]

>> When you install a package whose purpose is to change the user 
>> interface, you expect it will change the user interface, don't you? 
>> When you install an ad-blocker in your browser, you expect it will 
>> block ads, don't you?
>
> Again, the browser is a different situation.
>

For most users, it is not.  I guess you think the browser or GIMP are 
different situations, because you see them as mere tools, whereas you see 
Emacs as "more than a tool".  That's not the case for most Emacs users, 
for them Emacs is just a tool.  FWIW, when I open another editor, I see 
and use it as a mere tool for another task.

>
> This kind of aggressive behaviour just makes harder because you don't 
> know what is going on. This is how you confuse newcomers.
>

Regular users don't want to know what is going on, they don't care, and 
shouldn't have to care; for them an editor is just a tool for another 
task.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

> [Why did you write your first mail off-list, your second one Cc'd to
> emacs-devel, and your third one Cc'd to help-gnu-emacs?]

Sorry about that, forgot to Cc in the first message, and then I resent
the message to the wrong list.

>>> When you install a package whose purpose is to change the user
>>> interface, you expect it will change the user interface, don't you? 
>>> When you install an ad-blocker in your browser, you expect it will
>>> block ads, don't you?
>>
>> Again, the browser is a different situation.
>
> For most users, it is not.  I guess you think the browser or GIMP are
> different situations, because you see them as mere tools, whereas you
> see Emacs as "more than a tool".  That's not the case for most Emacs
> users, for them Emacs is just a tool.  FWIW, when I open another
> editor, I see and use it as a mere tool for another task.

No, the difference is that Emacs is a interactive computing environment
while GIMP and browsers are programs with extension models. But that's
not my main point:

All in all, I don't have a problem with Emacs being able to support it,
but as I've shown with the example in my last message, it doesn't need
to be done automatically, nor does it require a separate key. It's
ultimately up to the user what he or she wants to do, and clever
behind-your-back customization seems more harmful and confusing than the
current state of affairs.

>> This kind of aggressive behaviour just makes harder because you
>> don't know what is going on. This is how you confuse newcomers.
>
> Regular users don't want to know what is going on, they don't care,
> and shouldn't have to care; for them an editor is just a tool for
> another task.

I don't like the notion of a "regular user", but in principle I
agree. The open question is what this means. I don't think users should
be obstructed and confused, and I fear that what you propose has the
danger to do just that.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip K.]

[-- Attachment #1.1: Type: text/plain, Size: 500 bytes --]

"Philip K." <philipk@posteo.net> writes:

> All in all, I don't have a problem with Emacs being able to support it,
> but as I've shown with the example in my last message, it doesn't need
> to be done automatically, nor does it require a separate key. It's
> ultimately up to the user what he or she wants to do, and clever
> behind-your-back customization seems more harmful and confusing than the
> current state of affairs.

Just for the sake of it, this is a draft of how this could look like:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-Add-package-suggest-configuration.patch --]
[-- Type: text/x-patch, Size: 6146 bytes --]

From 3e78e4e61462f116a56224e0750401e9b9596e1f Mon Sep 17 00:00:00 2001
From: Philip K <philipk@posteo.net>
Date: Thu, 11 Feb 2021 16:30:09 +0100
Subject: [PATCH] Add package-suggest-configuration

---
 lisp/emacs-lisp/package.el | 99 ++++++++++++++++++++++++++++++++------
 1 file changed, 85 insertions(+), 14 deletions(-)

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 90b7b88d58..6ddd363003 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -145,6 +145,7 @@
 
 (require 'cl-lib)
 (eval-when-compile (require 'subr-x))
+(eval-when-compile (require 'pcase))
 (eval-when-compile (require 'epg))      ;For setf accessors.
 (require 'seq)
 
@@ -2087,6 +2088,88 @@ package--archives-initialize
   (unless package-archive-contents
     (package-refresh-contents)))
 
+(defcustom package-ignore-suggestions nil
+  "Should package-"
+  :type '(choice (const :tag "Ask the user" nil)
+                 (const :tag "Never ask" t)
+                 (set :tag "Ignore certain suggestions"
+                      (const :tag "Keybindings" key)
+                      (const :tag "User Options" option)
+                      (const :tag "Hooks" hook)))
+  :version "28.1")
+
+(defvar pacakge-configuration-suggestions nil
+  "An alist of advertised default configuration.
+Each entry has the form (PACKAGE . SUGGESTIONS), where PACAKGE is
+a symbol designating the package, and SUGGESTIONS is another
+alist.  SUGGESTIONS have the form (TYPE . DATA), where TYPE says
+what kind of a suggestion is being made and DATA is the content
+of the suggestion.  Currently, the following values for TYPE are
+understood:
+
+- `key', where DATA has the form (KEY FUNCTION).  It suggests
+  binding FUNCTION globally to KEY, unless KEY is already bound.
+  KEY is passed to the function `kbd'.
+
+- `option', where DATA has the form (OPT VAL).  It setting the
+  symbol OPT to the value VAL.
+
+- `hook', where DATA has the form (HOOK FUNCTION).  It suggests
+  adding FUNCTION to the hook HOOK.
+
+All other values for TYPE are ignored.")
+
+(defun package--query-name (&optional kind verb)
+  "Query the user for a package name.
+If KIND is nil, prompt for all kinds of packages.  If KIND is
+`installed' only prompt for installed packages.  If KIND is
+`not-installed', only prompt for packages that have not been
+installed.  VERB modified to prompt."
+  ;; Initialize the package system to get the list of package
+  ;; symbols for completion.
+  (package--archives-initialize)
+  (intern (completing-read
+           (format "%s package: " (or verb "Select"))
+           (delq nil (mapcar (lambda (elt)
+                               (when (cond
+                                      ((eq kind 'installed)
+                                       (package-installed-p (car elt)))
+                                      ((eq kind 'not-installed)
+                                       (not (package-installed-p (car elt))))
+                                      ((null kind))
+                                      (t (error "Invalid kind")))
+                                 (symbol-name (car elt))))
+                             package-archive-contents))
+           nil t)))
+
+(defun package-suggest-configuration (package &optional dont-load)
+  "Query the user to automatically configure PACKAGE.
+If DONT-LOAD is non-nil, do not load the new customization."
+  (interactive (list (package--query-name 'installed) current-prefix-arg))
+  (unless (and (not (called-interactively-p 'any))
+               (eq package-ignore-suggestions t))
+    (let ((temp-buffer-show-function #'ignore)
+          (save-silently t))
+      (with-temp-buffer
+        (with-output-to-temp-buffer (current-buffer)
+          (dolist (sug (cdr (assq package pacakge-configuration-suggestions)))
+            (unless (memq (car sug) package-ignore-suggestions)
+              (terpri nil t)
+              (pcase sug
+                (`(key ,key ,fn)
+                 (when (yes-or-no-p (format "Bind %s to \"%s\"?" fn key))
+                   (prin1 `(global-set-key (kbd ,key) #',fn))))
+                (`(option ,opt ,val)
+                 (when (yes-or-no-p (format "Set option %s to %S?" opt val))
+                   (prin1 `(customize-set-variable ',opt ,val))))
+                (`(hook ,hook ,fn)
+                 (when (yes-or-no-p (format "Add %s to hook %S?" fn hook))
+                   (prin1 `(add-hook ',hook #',fn)))))))
+          (unless dont-load
+            (eval-buffer))
+          (append-to-file (point-min) (point-max)
+                          (or custom-file user-init-file)))))))
+
 ;;;###autoload
 (defun package-install (pkg &optional dont-select)
   "Install the package PKG.
@@ -2103,20 +2186,7 @@ package-install
 
 If PKG is a `package-desc' and it is already installed, don't try
 to install it but still mark it as selected."
-  (interactive
-   (progn
-     ;; Initialize the package system to get the list of package
-     ;; symbols for completion.
-     (package--archives-initialize)
-     (list (intern (completing-read
-                    "Install package: "
-                    (delq nil
-                          (mapcar (lambda (elt)
-                                    (unless (package-installed-p (car elt))
-                                      (symbol-name (car elt))))
-                                  package-archive-contents))
-                    nil t))
-           nil)))
+  (interactive (list (package--query-name 'not-installed "Install")))
   (package--archives-initialize)
   (add-hook 'post-command-hook #'package-menu--post-refresh)
   (let ((name (if (package-desc-p pkg)
@@ -2134,6 +2204,7 @@ package-install
         (progn
           (package-download-transaction transaction)
           (package--quickstart-maybe-refresh)
+          (package-suggest-configuration pkg)
           (message  "Package `%s' installed." name))
       (message "`%s' is already installed" name))))
 
-- 
2.29.2


[-- Attachment #1.3: Type: text/plain, Size: 19 bytes --]


-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>
> the difference is that Emacs is a interactive computing environment 
> while GIMP and browsers are programs with extension models.
>

I'm not sure I understand the difference, and for most users Emacs is not 
an "interactive computing environment", it's a text editor, like Atom, 
Visual Studio, or Vim.

>
> All in all, I don't have a problem with Emacs being able to support it, 
> but as I've shown with the example in my last message, it doesn't need 
> to be done automatically, nor does it require a separate key.
>

The problem of what you propose is that, even if it were possible (AFAIU 
it isn't, given Emacs' key binding conventions), it would be a very 
limited solution: there are only 26 keys reserved for users.  Okay, 52, if 
you count capital letters.

>
> It's ultimately up to the user what he or she wants to do, and clever 
> behind-your-back customization seems more harmful and confusing than the 
> current state of affairs.
>

It's what most users expect.  apt install elpa-magit, C-x g, and voilà: 
Magit works.  BTW, Emacs already does "behind-your-back" customizations, 
and doesn't ask you any questions for them.  It provides sensible 
defaults, which work in most cases, and which you can change if need be.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>> the difference is that Emacs is a interactive computing environment
>> while GIMP and browsers are programs with extension models.
>
> I'm not sure I understand the difference, and for most users Emacs is
> not an "interactive computing environment", it's a text editor, like
> Atom, Visual Studio, or Vim.

Just because it appears to be something at first glance, doesn't mean it
should behave/limit itself to this misapprehension.

>> All in all, I don't have a problem with Emacs being able to support
>> it, but as I've shown with the example in my last message, it
>> doesn't need to be done automatically, nor does it require a
>> separate key.
>>
>
> The problem of what you propose is that, even if it were possible
> (AFAIU it isn't, given Emacs' key binding conventions), it would be a
> very limited solution: there are only 26 keys reserved for users.
> Okay, 52, if you count capital letters.

Wait, if a key were designated, you would have the same issue? But even
then, you can bind a key to a sub-map, you can rebind exiting keys if a
package improves on an existing key and you could suggest more than one
key.

>> It's ultimately up to the user what he or she wants to do, and
>> clever behind-your-back customization seems more harmful and
>> confusing than the current state of affairs.
>
> It's what most users expect.  apt install elpa-magit, C-x g, and
> voilà: Magit works. 

How do you come to this conclusion? And why does it matter if it is a
"wrong" expectation?

> BTW, Emacs already does "behind-your-back" customizations, and doesn't
> ask you any questions for them.  It provides sensible defaults, which
> work in most cases, and which you can change if need be.

I don't get your point here. Are you saying "default Emacs" is a
"behind-your-back customization"?

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>> The problem of what you propose is that, even if it were possible 
>> (AFAIU it isn't, given Emacs' key binding conventions), it would be a 
>> very limited solution: there are only 26 keys reserved for users. Okay, 
>> 52, if you count capital letters.
>
> Wait, if a key were designated, you would have the same issue? But even 
> then, you can bind a key to a sub-map, you can rebind exiting keys if a 
> package improves on an existing key and you could suggest more than one 
> key.
>

No, with one control key you have all characters (not just letters, also 
digits and symbols), plus all C-something, plus all M-something, plus 
C-M-something.  With one control key and its corrsponding meta key you 
multiply that number by two.

>> It's what most users expect.  apt install elpa-magit, C-x g, and voilà: 
>> Magit works.
>
> How do you come to this conclusion?
>

It's what Magit (and other similar packages) do.  The presupposition of 
the proposal is that such packages know their users.

>> BTW, Emacs already does "behind-your-back" customizations, and doesn't 
>> ask you any questions for them.  It provides sensible defaults, which 
>> work in most cases, and which you can change if need be.
>
> I don't get your point here. Are you saying "default Emacs" is a 
> "behind-your-back customization"?
>

No, I mean that installing packages already does some "behind-your-back" 
customizations, for example by modifying auto-mode-alist.  There are cases 
when such modifications do not what some particular user would expect; as 
someone mentioned, a package for Perl who would override the setting of a 
package for Prolog because both use the .pl extension.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 2882 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

> No, with one control key you have all characters (not just letters,
> also digits and symbols), plus all C-something, plus all M-something,
> plus C-M-something.  With one control key and its corrsponding meta
> key you multiply that number by two.

Ah ok, I get what you mean. Does it really make that much of a
difference? I'm not sure how many packages you are expecting would add
default bindings (or how conflict resolution should happen), but do you
really need more than 26? How many packages do people install, where an
interactive command is the entry-point _and_ has to be bound to a key by
default? In my case it is only Magit, and that's bound to C-c g without
any problems.

Also, here's another annoyance: What if I don't like the default
binding? How would you expect this to be modified? Would a package
constantly try to modify my config to add what it thinks should be the
right key to trigger the right command?

>>> It's what most users expect.  apt install elpa-magit, C-x g, and
>>> voilà: Magit works.
>>
>> How do you come to this conclusion?
>
> It's what Magit (and other similar packages) do.  The presupposition
> of the proposal is that such packages know their users.

I only know of Magit that does it, and as I have said before, I think it
is a mistake and unfriendly. But that still doesn't answer the
question. Why do you think that users expect it -- not the image that
magit has it it's users.

>>> BTW, Emacs already does "behind-your-back" customizations, and
>>> doesn't ask you any questions for them.  It provides sensible
>>> defaults, which work in most cases, and which you can change if
>>> need be.
>>
>> I don't get your point here. Are you saying "default Emacs" is a
>> "behind-your-back customization"?
>
> No, I mean that installing packages already does some
> "behind-your-back" customizations, for example by modifying
> auto-mode-alist.  There are cases when such modifications do not what
> some particular user would expect; as someone mentioned, a package for
> Perl who would override the setting of a package for Prolog because
> both use the .pl extension.

Yes, and as I have said in a previous message (or in my article for that
matter), I think it is problematic. Lucky the situation with
auto-mode-alist is more relaxed, since auto-mode-list benefits from the
fact that file extensions tend not to conflict with one-another
(survival of the more popular).

Also, if I am not mistaken, packages that manipulate auto-mode-alist add
their entry to the end of the list, so that if a user wants to interpret
.pl as whatever they want, they won't interfere. This kind of a respect
for the user would have to be necessary for what you propose, so that an
implicit Emacs etiquette is preserved.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>> No, with one control key you have all characters (not just letters, 
>> also digits and symbols), plus all C-something, plus all M-something, 
>> plus C-M-something.  With one control key and its corrsponding meta key 
>> you multiply that number by two.
>
> Ah ok, I get what you mean. Does it really make that much of a 
> difference? I'm not sure how many packages you are expecting would add 
> default bindings (or how conflict resolution should happen), but do you 
> really need more than 26?
>

That reminds me the famous "640 kb should be enough for anyone" ;-) 
Indeed, 26 letters is not enough.  Magit has three global commands, 
Org-mode has three, and Bookmark+ has three keymaps.  With just three 
packages you've already used 35% of the available keys.  I hope you 
understand that it can't be a long-term solution.  Moreover, AFAIU, 
packages cannot automatically bind their commands to C-c LETTER keys 
anyway: these keys are strictly reserved for users in their personal 
configuration files.

>>>> It's what most users expect.  apt install elpa-magit, C-x g, and 
>>>> voilà: Magit works.
>>>
>>> How do you come to this conclusion?
>>
>> It's what Magit (and other similar packages) do.  The presupposition of 
>> the proposal is that such packages know their users.
>
> I only know of Magit that does it, and as I have said before, I think it 
> is a mistake and unfriendly. But that still doesn't answer the question. 
> Why do you think that users expect it -- not the image that magit has it 
> it's users.
>

Being a programmer, I can understand your viewpoint.  As a user I can't. 
With M-x load-theme <something>, the user interface changes.  What makes 
keybindings so different from user interface colors that they should 
absolutely not be touched when a package is loaded, say with M-x 
global-foobar-mode, and require an explicit manual configuration by the 
user?  Do you also think it's a mistake and unfriendly if a package 
installs a menu item?  If not, what makes keybindings fundamentally 
different from menu items?

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 3309 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>> No, with one control key you have all characters (not just letters,
>>> also digits and symbols), plus all C-something, plus all
>>> M-something, plus C-M-something.  With one control key and its
>>> corrsponding meta key you multiply that number by two.
>>
>> Ah ok, I get what you mean. Does it really make that much of a
>> difference? I'm not sure how many packages you are expecting would
>> add default bindings (or how conflict resolution should happen), but
>> do you really need more than 26?
>>
>
> That reminds me the famous "640 kb should be enough for anyone" ;-)
> Indeed, 26 letters is not enough.  Magit has three global commands, 
> Org-mode has three, and Bookmark+ has three keymaps.  With just three
> packages you've already used 35% of the available keys.  I hope you 
> understand that it can't be a long-term solution.  Moreover, AFAIU,
> packages cannot automatically bind their commands to C-c LETTER keys 
> anyway: these keys are strictly reserved for users in their personal
> configuration files.

I think that's the pessimistic way to look at it, the optimistic one
would be to say that you only need 35% of the key-space. I don't have a
feeling for how many global keys people bind by default, one would have
to study public configurations to find out. But I still remain sceptical
that -- compared to memory usage -- that need for keys is rising that
much.

>> I only know of Magit that does it, and as I have said before, I
>> think it is a mistake and unfriendly. But that still doesn't answer
>> the question. Why do you think that users expect it -- not the image
>> that magit has it it's users.
>>
>
> Being a programmer, I can understand your viewpoint.  As a user I
> can't. With M-x load-theme <something>, the user interface changes.

Well I install a package with M-x package-install, right? Not M-x
package-init or M-x package-load. When I install a program via my
package manager, I don't expect it to start immediately. It is just
expected that it is ready. And package-install does just that, and I
hope it is not just me, but that's what I would guess a command named
"package install" would do.

> What makes keybindings so different from user interface colors that
> they should absolutely not be touched when a package is loaded, say
> with M-x global-foobar-mode, and require an explicit manual
> configuration by the user?

A theme doesn't activate when it is installed or loaded, but when it is
activated. In the same way, I argue, a command shouldn't bind itself
until it is bound. Note that I don't insist that this has to be done
by editing your init.el (as shown in the patch from a few messages
before). I just think that loading a feature/package should attempt to
just load the package, without changing the UI/UX of the system.

> Do you also think it's a mistake and unfriendly if a package installs
> a menu item?  If not, what makes keybindings fundamentally different
> from menu items?

Do you mean a menu-bar-mode item? Yes, loading a package still shouldn't
change anything, activating a mode should add the menu item, so that it
is clear to the user what caused the change, and how it can be reversed.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>
> A theme doesn't activate when it is installed or loaded, but when it is 
> activated. In the same way, I argue, a command shouldn't bind itself 
> until it is bound. Note that I don't insist that this has to be done by 
> editing your init.el (as shown in the patch from a few messages before). 
> I just think that loading a feature/package should attempt to just load 
> the package, without changing the UI/UX of the system.
>

I fear you're splitting hairs here: the distinction between "install", 
"load" and "activate" is not important in this discussion, with the 
current state of affairs neither installing nor loading nor activating the 
package can automatically create a global key binding.  The proposal is an 
attempt to make that possible.

>> Do you also think it's a mistake and unfriendly if a package installs a 
>> menu item?  If not, what makes keybindings fundamentally different from 
>> menu items?
>
> Do you mean a menu-bar-mode item? Yes, loading a package still shouldn't 
> change anything, activating a mode should add the menu item
>

Okay, so if you agree that activating a mode can automatically add a menu 
bar item, why don't you agree that it should be possible to automatically 
add a global key binding while activating a mode?  Again, what makes key 
bindings fundamentally different from menu bar items?

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 4374 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>> A theme doesn't activate when it is installed or loaded, but when it
>> is activated. In the same way, I argue, a command shouldn't bind
>> itself until it is bound. Note that I don't insist that this has to
>> be done by editing your init.el (as shown in the patch from a few
>> messages before). I just think that loading a feature/package should
>> attempt to just load the package, without changing the UI/UX of the
>> system.
>
> I fear you're splitting hairs here: the distinction between "install",
> "load" and "activate" is not important in this discussion, with the 
> current state of affairs neither installing nor loading nor activating
> the package can automatically create a global key binding.  The
> proposal is an attempt to make that possible.

Well none of these should so it, with the possible exception of
activating, that I'll mention again below. But I still think that the
distinction is important, if only because it is real. I recently
realized there would be another problem with this approach, as you also
mentioned that global modes should activate themselves on installation,
specifically naming Ivy, the completing-read framework. But what if
someone decides to install Helm? Will these two modes now interfere,
possibly breaking everything, or is it Helm's responsibility to
deactivate Ivy. If so, does every completion framework have to know
about every other one?

I think this shows that adding code like

        ;;;###autoload
        (ivy-mode t)

is bad style, even if a beginner manages to deactivate Ivy or Helm, the
same issue would arise every time Emacs is restarted, which creates the
feeling that the entire system is fragile -- and it is, because
fundamental operations like "install", "load" and "activate" are kept
apart.

As for key-bindings, if we assume that like Magit, any package can just
autoload a global-set-key, we are just inviting bug-reports complaining
about "Key sequence [something] starts with non-prefix key [something
else]", or key-bindings being over-ridden or chaining from session to
session.

Situations like these, tell me that adding user-customization directly
as autoloaded code is harmful and would at least require a level of
abstraction in-between.

>>> Do you also think it's a mistake and unfriendly if a package
>>> installs a menu item?  If not, what makes keybindings fundamentally
>>> different from menu items?
>>
>> Do you mean a menu-bar-mode item? Yes, loading a package still
>> shouldn't change anything, activating a mode should add the menu
>> item
>
> Okay, so if you agree that activating a mode can automatically add a
> menu bar item, why don't you agree that it should be possible to
> automatically add a global key binding while activating a mode?
> Again, what makes key bindings fundamentally different from menu bar
> items?

Activating a mode and deactivating a mode are "inverse" operations. This
is important, because it makes mode activation reversible, and lets the
user feel like he or she is in control. Therefore, if a
global-minor-mode, which I assume we are talking about, binds a global
key, it must not only un-bind it when it is done, but restore the
previous binding, if there was one. The tricky part is now if a second
global-minor-mode comes along, and wants to rebind the same key, also
saves the same command and then installs it's command: Now deactivating
the first mode would either have to check if the key it has bound is
still bound, and only undo it's operation if that is the case, or it
just re-binds the old key, overriding the binding of the second minor
mode. Neither of these are good approaches, and they cannot be resolved
without both global-minor-modes either knowing details about one-another
or having a protocol they follow to save keys.

The difference to menu items is that collisions like these are not
possible, you just add and remove an item from a list, without having to
fear collision (with the possible exception of having two items have the
same name, but that's an issue on a different level).

This demonstrates why a mode binding a key to the global-map is
difficult, and why it should instead use it's own map, that is installed
when said mode is activated.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>> I fear you're splitting hairs here: the distinction between "install", 
>> "load" and "activate" is not important in this discussion, with the 
>> current state of affairs neither installing nor loading nor activating 
>> the package can automatically create a global key binding.  The 
>> proposal is an attempt to make that possible.
>
> Well none of these should so it, with the possible exception of 
> activating, that I'll mention again below. But I still think that the 
> distinction is important, if only because it is real. I recently 
> realized there would be another problem with this approach, as you also 
> mentioned that global modes should activate themselves on installation, 
> specifically naming Ivy, the completing-read framework. But what if 
> someone decides to install Helm? Will these two modes now interfere, 
> possibly breaking everything, or is it Helm's responsibility to 
> deactivate Ivy. If so, does every completion framework have to know 
> about every other one?
>

That question and the problems you raise are orthogonal to the problem at 
hand.  I did not say that the distinction isn't important in general, only 
that it isn't relevant for the problem that the proposal attempts to 
solve.

I have no opinion about whether it is better for packages to install 
global bindings at installation time, at loading time or at activation 
time.  At first sight it seems to me that all three could make sense, 
depending on the package.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>> Well none of these should so it, with the possible exception of
>> activating, that I'll mention again below. But I still think that
>> the distinction is important, if only because it is real. I recently 
>> realized there would be another problem with this approach, as you
>> also mentioned that global modes should activate themselves on
>> installation, specifically naming Ivy, the completing-read
>> framework. But what if someone decides to install Helm? Will these
>> two modes now interfere, possibly breaking everything, or is it
>> Helm's responsibility to deactivate Ivy. If so, does every
>> completion framework have to know about every other one?
>
> That question and the problems you raise are orthogonal to the problem
> at hand.  I did not say that the distinction isn't important in
> general, only that it isn't relevant for the problem that the proposal
> attempts to solve.
>
> I have no opinion about whether it is better for packages to install
> global bindings at installation time, at loading time or at activation 
> time.  At first sight it seems to me that all three could make sense,
> depending on the package.

I do think that the problems are relevant, because they show that
activation at install- or load-time are bad style. The only real choice
is activation-time, but that won't work for examples like Magit, since
they are not activated using modes. I'm not sure how I'd feel about a
magit-global-mode...

The only real solution that I see is something along the lines of what I
recommended: Packages suggest customizations, and package-install may
either ignore, ask for confirmation or accept them by default, if there
are no problems with what is suggested (eg. collisions). This avoids all
of the issues I have mentioned, will make it easier for newcomers
without annoying existing users, at minimal expense to package
maintainers, while providing information that can even be used by other
third-party packages (e.g. use-package can use the suggestions to
automatically build a configuration block).

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>> I have no opinion about whether it is better for packages to install 
>> global bindings at installation time, at loading time or at activation 
>> time.  At first sight it seems to me that all three could make sense, 
>> depending on the package.
>
> I do think that the problems are relevant, because they show that 
> activation at install- or load-time are bad style. The only real choice 
> is activation-time, but that won't work for examples like Magit, since 
> they are not activated using modes. I'm not sure how I'd feel about a 
> magit-global-mode...
>

As I said, I have no opinion about which moment is better.  But it seems 
to me that "the only real choice is activation-time" is wrong.  It depends 
on how much that package modifies the user interface.  Magit is a good 
example in that respect: nothing is changed, except three global key 
bindings.  There are other cases, imagine a package implementing a global 
command to query the stock price of the string under point to display it 
in the minibuffer.  It would make sense that installing that package 
binds, say, "C-\alpha $" to its command "display-stock-price", if that key 
is still available, without asking the user whether they really want that 
binding.  Other package authors may prefer to delay that binding until the 
package is loaded with a "require" or "load".  Yet others may prefer to 
delay that binding until the package is explicitly activated with M-x or 
in the users' init file.

>
> The only real solution that I see is something along the lines of what I 
> recommended: Packages suggest customizations, and package-install may 
> either ignore, ask for confirmation or accept them by default, if there 
> are no problems with what is suggested (eg. collisions).
>

And that solution cannot be implemented if there is no key space reserved 
for third-party libraries.  Which is what the proposal is about.  The 
proposal is not about the particular mechanisms that could be used to bind 
keys in that reserved area.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>> The only real solution that I see is something along the lines of
>> what I recommended: Packages suggest customizations, and
>> package-install may either ignore, ask for confirmation or accept
>> them by default, if there are no problems with what is suggested
>> (eg. collisions).
>
> And that solution cannot be implemented if there is no key space
> reserved for third-party libraries.  Which is what the proposal is
> about.  The proposal is not about the particular mechanisms that could
> be used to bind keys in that reserved area.

I argue it can be done, and that the proposal to have packages suggest
keys to bind would avoid the need to designate a special key space for
third-party packages. That is why I'm brining it up.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>>> The only real solution that I see is something along the lines of what 
>>> I recommended: Packages suggest customizations, and package-install 
>>> may either ignore, ask for confirmation or accept them by default, if 
>>> there are no problems with what is suggested (eg. collisions).
>>
>> And that solution cannot be implemented if there is no key space 
>> reserved for third-party libraries.  Which is what the proposal is 
>> about.  The proposal is not about the particular mechanisms that could 
>> be used to bind keys in that reserved area.
>
> I argue it can be done, and that the proposal to have packages suggest 
> keys to bind would avoid the need to designate a special key space for 
> third-party packages.
>

I must have misunderstood something in your solution.  What are the 
possible keys a package could suggest, with your solution?  What is the 
set of keys in which package developers can choose keys to suggest to 
their users?

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 4172 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>>> The only real solution that I see is something along the lines of
>>>> what I recommended: Packages suggest customizations, and
>>>> package-install may either ignore, ask for confirmation or accept
>>>> them by default, if there are no problems with what is suggested
>>>> (eg. collisions).
>>>
>>> And that solution cannot be implemented if there is no key space
>>> reserved for third-party libraries.  Which is what the proposal is 
>>> about.  The proposal is not about the particular mechanisms that
>>> could be used to bind keys in that reserved area.
>>
>> I argue it can be done, and that the proposal to have packages
>> suggest keys to bind would avoid the need to designate a special key
>> space for third-party packages.
>
> I must have misunderstood something in your solution.  What are the
> possible keys a package could suggest, with your solution?  What is
> the set of keys in which package developers can choose keys to suggest
> to their users?

My apologies if I was unclear, I'll try to rephrase it so that you
understand where I'm coming from (and sorry, again, for the wall of
text):

Beginning from the fact, that I don't see any key that is common, unused
AND practical, I think we must accept that packages are actually limited
to those keys reserved for users (or user-configurations).

Usually, packages like Magit, Org, elfeed, etc. can only informally
propose a key-binding to use, users have to read this and install it
themselves. Works for you and me, but can be confusing to others.

My suggestion is based on the introduction of two variables: One for
packages to formally specify their suggestions for what keys to bind,
what hooks to modify, what options to set, etc. and one for users to
declare if they are interested or not.

The patch I added to a message proposed that eg. Magit wouldn't write
something like

        ;;;###autoload
        (global-set-key (kbd "C-x g") #'magit-status)

(I'm oversimplifying, their code is more complex), but instead they add
a line like

        ;;;###autoload
        (add-to-list 'pacakge-configuration-suggestions
                     '(magit            ; package name
                       (key             ; what type of suggestion 
                        "C-x g"         ; what key to bind the following to
                        magit-status    ; what command to bind
                        )))

This is one way, another one would be to use the header, but that's a
bit more complicated.

Now that the package has been installed and the suggestion has been
noted, Emacs would check a user-option I've named
`package-ignore-suggestions' but could be more general if the user is
interested in recommended key-binding suggestions. If this is the case,
package-install would immediately query ask the user if something like

                (global-set-key (kbd "C-x g") #'magit-status)

should be added to the user configuration. In my patch this was just a
yes or no question, but a more serious implementation could also
support a list of key-chords, only suggesting those that have not been
bound yet, and allowing the user to set their own key-binding. Ideally,
every suggestion should also have a justification explaining why it
proposes this modification.

As I've implied, `package-ignore-suggestions' could be transformed to
just accept anything a package proposes, notifying the user that after
installing, e.g. Magit, C-x g has been bound.

So, this modifies as little as possible (just noting suggestions that
don't interest the user) in a program-friendly format that can be
expanded to code in the user-configuration. This can then be modified,
and these configurations wouldn't be changed by package
updated. Package.el ensures that the user isn't confused, is notified of
changes and gets to decide what he or she wants. 

It seems to me that this is the minimal abstraction layer necessary for
packages to configure themselves while maintaining good style, or at
least what I understand good style to be.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

Thanks for your detailed answer!

>
> Beginning from the fact, that I don't see any key that is common, unused 
> AND practical, I think we must accept that packages are actually limited 
> to those keys reserved for users (or user-configurations).
>

Well, that's exactly what the proposal attempts to fix ;-)

>
> Usually, packages like Magit, Org, elfeed, etc. can only informally 
> propose a key-binding to use, users have to read this and install it 
> themselves. Works for you and me, but can be confusing to others.
>

Yes, exactly.

>
> My suggestion is based on the introduction of two variables: One for 
> packages to formally specify their suggestions for what keys to bind, 
> what hooks to modify, what options to set, etc. and one for users to 
> declare if they are interested or not.
>
> The patch I added to a message proposed that eg. Magit wouldn't write 
> something like
>
>        ;;;###autoload
>        (global-set-key (kbd "C-x g") #'magit-status)
>
> (I'm oversimplifying, their code is more complex), but instead they add 
> a line like
>
>        ;;;###autoload
>        (add-to-list 'pacakge-configuration-suggestions
>                     '(magit            ; package name
>                       (key             ; what type of suggestion
>                        "C-x g"  ; what key to bind the following to
>                        magit-status ; what command to bind
>                       )))
>

I'm fine with this in principle, but it doesn't answer the question.  In 
the above example Magit would suggest "C-x g".  It can do this because at 
the moment that key isn't used by Emacs.  There is no guarantee that that 
key will not at some point be reclaimed by Emacs.  It cannot suggest a 
"C-c LETTER" key, these are AFAIU strictly reserved for users in their 
configuration files, and there are not enough available keys there so this 
cannot be a long term solution anyway.  So what keys can it suggest? 
This, and only this, is what the proposal is about.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>> My suggestion is based on the introduction of two variables: One for
>> packages to formally specify their suggestions for what keys to
>> bind, what hooks to modify, what options to set, etc. and one for
>> users to declare if they are interested or not.
>>
>> The patch I added to a message proposed that eg. Magit wouldn't
>> write something like
>>
>>        ;;;###autoload
>>        (global-set-key (kbd "C-x g") #'magit-status)
>>
>> (I'm oversimplifying, their code is more complex), but instead they
>> add a line like
>>
>>        ;;;###autoload
>>        (add-to-list 'pacakge-configuration-suggestions
>>                     '(magit            ; package name
>>                       (key             ; what type of suggestion
>>                        "C-x g"  ; what key to bind the following to
>>                        magit-status ; what command to bind
>>                       )))
>>
>
> I'm fine with this in principle, but it doesn't answer the question.
> In the above example Magit would suggest "C-x g".  It can do this
> because at the moment that key isn't used by Emacs.  There is no
> guarantee that that key will not at some point be reclaimed by Emacs.
> It cannot suggest a "C-c LETTER" key, these are AFAIU strictly
> reserved for users in their configuration files, and there are not
> enough available keys there so this cannot be a long term solution
> anyway.  So what keys can it suggest? This, and only this, is what the
> proposal is about.

My reading of the guideline on "C-c LETTER" is that a major/minor mode
shouldn't bind C-c LETTER to a command, so that it overshadows whatever
is bound globally to C-c LETTER. But a system like what I propose just
generates to configuration *for* the user, in a user file in which case
the guideline doesn't apply. That's what I mean by avoiding the need for
an extra key-space.

Of course, if some way could be found to reserve a prefix for
third-party packages, pacakge-configuration-suggestions could always
use this too -- my suggestion just anticipates that this will probably
not happen and tries to solve the problem in a different way.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>
> My reading of the guideline on "C-c LETTER" is that a major/minor mode 
> shouldn't bind C-c LETTER to a command, so that it overshadows whatever 
> is bound globally to C-c LETTER. But a system like what I propose just 
> generates to configuration *for* the user, in a user file in which case 
> the guideline doesn't apply. That's what I mean by avoiding the need for 
> an extra key-space.
>

I'm not sure your interpetation of that guideline ("Don't define 'C-c 
LETTER' as a key in Lisp programs") is correct, but now at least I see 
what you mean: you're more or less cheating the guideline by generating a 
configuration file, after asking the user if they're okay with that, 
instead of binding the key directly in the package depending on the value 
of a configuration variable.  To me what you propose looks pretty close to 
using customize to set a foobar-set-global-binding variable that would be 
used in a call to global-set-key.

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.

>
> Of course, if some way could be found to reserve a prefix for 
> third-party packages,
>

Again: this, to reserve prefix key(s) for third-party packages, and only 
this, is what the proposal is about.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>> My reading of the guideline on "C-c LETTER" is that a major/minor
>> mode shouldn't bind C-c LETTER to a command, so that it overshadows
>> whatever is bound globally to C-c LETTER. But a system like what I
>> propose just generates to configuration *for* the user, in a user
>> file in which case the guideline doesn't apply. That's what I mean
>> by avoiding the need for an extra key-space.
>>
>
> I'm not sure your interpetation of that guideline ("Don't define 'C-c
> LETTER' as a key in Lisp programs") is correct, but now at least I see 
> what you mean: you're more or less cheating the guideline by
> generating a configuration file, after asking the user if they're okay
> with that, instead of binding the key directly in the package
> depending on the value of a configuration variable.  To me what you
> propose looks pretty close to using customize to set a
> foobar-set-global-binding variable that would be used in a call to
> global-set-key.

Yes, that could also be done, the precise code that is generated is an
open question

> 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.

You could use C-c LETTER as a fallback, and suggest more convenient keys
first, that are usually unbound. But even considering that, what do you
think that the long-term issue is? Do you think that with time, people
will be using more and more packages that need global keys?

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>> To me what you propose looks pretty close to using customize to set a 
>> foobar-set-global-binding variable that would be used in a call to 
>> global-set-key.
>
> Yes, that could also be done, the precise code that is generated is an 
> open question
>

But that would be forbidden by the guideline "Don't define 'C-c LETTER' as 
a key in Lisp programs", wouldn't it?

(defcustom foobar-global-key "" "Foobar global key in C-c")
...
(if (length foobar-global-key)
   (global-set-key (kbd (concat "C-c " foobar-global-key) 'foobar-foo-command)))

If that's allowed, then why not this?

(defcustom foobar-global-key "z" "Foobar global key in C-c")
...
(if (length foobar-global-key)
   (global-set-key (kbd (concat "C-c " foobar-global-key) 'foobar-foo-command)))

This is not very different from the first one, and does what the guideline 
forbids, but it could be argued that it does not because it does so only 
conditionally...

>
> But even considering that, what do you think that the long-term issue 
> is? Do you think that with time, people will be using more and more 
> packages that need global keys?
>

I do not think, I see.  Just have a look at the starter kits, or at the 
init files of those who make them public.  You'll see that there are many 
packages that need global keys.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>> To me what you propose looks pretty close to using customize to set
>>> a foobar-set-global-binding variable that would be used in a call
>>> to global-set-key.
>>
>> Yes, that could also be done, the precise code that is generated is
>> an open question
>>
>
> But that would be forbidden by the guideline "Don't define 'C-c
> LETTER' as a key in Lisp programs", wouldn't it?

It seems to me that this is a matter of "in the word of the law" or "in
the spirit of the law". I understand the "spirit" of the guideline to be
saying that external code shouldn't try to bind keys that are reserved
for the users to decide what to bind. This is not because they are
external, but because they would make a decision for the user.

> (defcustom foobar-global-key "" "Foobar global key in C-c")
> ...
> (if (length foobar-global-key)
>   (global-set-key (kbd (concat "C-c " foobar-global-key) 'foobar-foo-command)))

This would be defined unconditionally too, I assume you wanted to set
the default value of foobar-global-key to nil and check if it is
non-nil. And even then, the binding should be done in the defcustom's
:set procedure, to make it reversible -- but that's not important here.

> If that's allowed, then why not this?
>
> (defcustom foobar-global-key "z" "Foobar global key in C-c")
> ...
> (if (length foobar-global-key)
>   (global-set-key (kbd (concat "C-c " foobar-global-key) 'foobar-foo-command)))
>
> This is not very different from the first one, and does what the
> guideline forbids, but it could be argued that it does not because it
> does so only conditionally...

Conditionally, yes, but also by *default*, which I think is the
problem. The default execution of this code would override whatever was
bound on C-c z, without asking the user -- and I see this as a violation
of guideline's "spirit".

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>> But that would be forbidden by the guideline "Don't define 'C-c LETTER' 
>> as a key in Lisp programs", wouldn't it?
>
> It seems to me that this is a matter of "in the word of the law" or "in 
> the spirit of the law". I understand the "spirit" of the guideline to be 
> saying that external code shouldn't try to bind keys that are reserved 
> for the users to decide what to bind. This is not because they are 
> external, but because they would make a decision for the user.
>

Indeed, my understanding of the "spirit of the law" is different: my 
understanding is that no code in a library should bind C-c LETTER key, 
conditionally or not, and that these keys are strictly reserved for users, 
who have to explicitly bind them in their init file.

AFAIU, this is also how the author of Magit understands that guideline: 
Magit binds three keys globally unless magit-define-global-key-bindings, 
whose default value is t, has been set to nil, and only recommends in the 
docstring to bind "C-c g".  With your understanding of the guideline, 
Magit could have added a third possible to 
magit-define-global-key-bindings, say 'best, with which the "C-c g" 
binding would have been created automatically.

Anyway, that question is, as I said, unrelated to the proposal itself.

>> (defcustom foobar-global-key "" "Foobar global key in C-c")
>> ...
>> (if (length foobar-global-key)
>>   (global-set-key (kbd (concat "C-c " foobar-global-key) 'foobar-foo-command)))
>
> This would be defined unconditionally too
>

Whoops, I wrote too fast indeed, of course it should have been (if (> 
(length foobar-global-key) 0)..., or perhaps (unless (string-empty-p 
foobar-global-key)...

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]


Sorry for protracting the conversation, I just think the interpretation
of the guideline is important.

Gregory Heytings <gregory@heytings.org> writes:

>>> But that would be forbidden by the guideline "Don't define 'C-c
>>> LETTER' as a key in Lisp programs", wouldn't it?
>>
>> It seems to me that this is a matter of "in the word of the law" or
>> "in the spirit of the law". I understand the "spirit" of the
>> guideline to be saying that external code shouldn't try to bind keys
>> that are reserved for the users to decide what to bind. This is not
>> because they are external, but because they would make a decision
>> for the user.
>
> Indeed, my understanding of the "spirit of the law" is different: my
> understanding is that no code in a library should bind C-c LETTER key, 
> conditionally or not, and that these keys are strictly reserved for
> users, who have to explicitly bind them in their init file.

This seems to be more of a literal interpretation, unless I'm missing
something. When talking about the "spirit of the law", I'm trying to
consider why a key-space would have been reserved for users. Or to put
it this way, the problem that the guideline tries to prevent is
primarily that {minor,major} modes don't shadow certain keys, and
secondarily that libraries don't override these same keys. I distinguish
between primary and secondary motivations, because the latter is
something that should be avoided in the first place, no matter what key
is bound.

Because what difference does it make who binds the key, or where it is
bound? You could have a function like

        (defun foo-bind-to (key)
          (global-set-key (kbd key) #'foo-function))

even though it is nonsensical, it violates what I consider the literal
interpretation (global-set-key is called from a library), but not how
I'm reading it (the user decides to call foo-bind-to, and might pass a
C-c LETTER for KEY).

> AFAIU, this is also how the author of Magit understands that
> guideline: Magit binds three keys globally unless
> magit-define-global-key-bindings, whose default value is t, has been
> set to nil, and only recommends in the docstring to bind "C-c g".
> With your understanding of the guideline, Magit could have added a
> third possible to magit-define-global-key-bindings, say 'best, with
> which the "C-c g" binding would have been created automatically.

No, because the user is not asked, and I have to add extra
configuration, to prevent Magit from changing my environment. This all
boils down to the question of what's better: Opt-in or Out-out -- I have
argued that these kind of things (modes, binding global keys, hook, ...)
should always be opt-in. What is ultimately considered good style is up
to the users to decide, but I'm not a fan of a configuration where most
of everything is just deactivating defaults.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Emanuel Berg via Users list for the GNU Emacs text editor]

Philip Kaludercic wrote:

> (defun foo-bind-to (key)
>   (global-set-key (kbd key) #'foo-function))
>
> even though it is nonsensical, it violates what I consider
> the literal interpretation (global-set-key is called from
> a library)

What is a library all of a sudden? A package?

There is nothing wrong with having Elisp help you assign keys.

On the contrary, that's how it is done :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Philip Kaludercic wrote:
>
>> (defun foo-bind-to (key)
>>   (global-set-key (kbd key) #'foo-function))
>>
>> even though it is nonsensical, it violates what I consider
>> the literal interpretation (global-set-key is called from
>> a library)
>
> What is a library all of a sudden? A package?

Oops, yes, I meant a package.

> There is nothing wrong with having Elisp help you assign keys.
>
> On the contrary, that's how it is done :)

My point was if a package provides function as the one above, you'd be
able to write

        (foo-bind-to "C-c a")

instead of

        (global-set-key (kbd "C-c a") #'foo-function)

which probably isn't worth it.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>
> Sorry for protracting the conversation, I just think the interpretation 
> of the guideline is important.
>

Not for the proposal itself.

>> Indeed, my understanding of the "spirit of the law" is different: my 
>> understanding is that no code in a library should bind C-c LETTER key, 
>> conditionally or not, and that these keys are strictly reserved for 
>> users, who have to explicitly bind them in their init file.
>
> This seems to be more of a literal interpretation, unless I'm missing 
> something.
>

Yes, indeed.

>> AFAIU, this is also how the author of Magit understands that guideline: 
>> Magit binds three keys globally unless 
>> magit-define-global-key-bindings, whose default value is t, has been 
>> set to nil, and only recommends in the docstring to bind "C-c g". With 
>> your understanding of the guideline, Magit could have added a third 
>> possible to magit-define-global-key-bindings, say 'best, with which the 
>> "C-c g" binding would have been created automatically.
>
> No, because the user is not asked, and I have to add extra 
> configuration, to prevent Magit from changing my environment.
>

The point here is that the three values for 
magit-define-global-key-bindings would have resulted in three behaviors: 
nil => do not bind any key, t => bind keys but not in C-c, 'best => bind 
keys including one in C-c.  The author of Magit did not do this, so my 
guess (it's just a guess, I could be wrong) is that he also has a literal 
interpretation of the guideline.

>
> This all boils down to the question of what's better: Opt-in or Out-out 
> -- I have argued that these kind of things (modes, binding global keys, 
> hook, ...) should always be opt-in.
>

This question comes closer to the proposal, I understand your point, and I 
do not agree.  As I said, you and me are developers, we know Emacs, we 
know how it works, we know how to do things.  Newcomers are perhaps not 
even developers, and even those who are shouln't have to do such things, 
just as you shouldn't have to add some JavaScript code in a configuration 
file of your browser to enable an extension.  Here's how the author of 
Magit explained why he added global bindings:

"Some [...] beginners will initially have a low threshold for things not 
working out of the box and I don't want to (continue to) scare them off by 
immediately forcing them to learn how to add key bindings and what that 
even means.  There's a lot of talk about making Emacs friendlier for 
beginners and this is a small step in that direction." [1]

The proposal goes exactly into that same direction, and has the same 
motivation.

[1] https://github.com/magit/magit/pull/4237#issuecomment-723495053

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-13 18:03]:
> "Some [...] beginners will initially have a low threshold for things not
> working out of the box and I don't want to (continue to) scare them off by
> immediately forcing them to learn how to add key bindings and what that even
> means.  There's a lot of talk about making Emacs friendlier for beginners
> and this is a small step in that direction." [1]
> 
> The proposal goes exactly into that same direction, and has the same
> motivation.
> 
> [1] https://github.com/magit/magit/pull/4237#issuecomment-723495053

"Emacs functions are defined within parenthesis like ( and ). The
items withn parenthesis are a list. That is why LISP as programming
language means LISt Processing. At first place of the list user would
give a command to computer such as `global-set-key' and at next
following places various parameters to the command.

Following LISP expression would place `magit-function' on the key
Control-c followed by the letter m.

(global-set-key (kbd "C-c m") 'magit-function)"

The above is my attempt to describe how one could describe a function.

Describing a function to teach users is equally costly effort just as
it is explaining how users need not be teached anything and treat them
as not very bright (mildly said).

Again:

> "Some [...] beginners will initially have a low threshold for things not
> working out of the box and I don't want to (continue to) scare them off by
> immediately forcing them to learn how to add key bindings and what that even
> means.  There's a lot of talk about making Emacs friendlier for beginners
> and this is a small step in that direction." [1]

So that comes from Magit? How can version control system developer
treat their users as not being very bright (I am just deliberately
avoiding saying "stupid")? Makes no logic to me.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> Emacs functions are defined within parenthesis like
> ( and ). The items withn parenthesis are a list. [...]

Well, in some sense I suppose, but technically, actually not
so:

(listp (defun dummy-function ()
         (message "darn good software") )) ; nil

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Nothing is the list - Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-13 18:31]:
> Jean Louis wrote:
> 
> > Emacs functions are defined within parenthesis like
> > ( and ). The items withn parenthesis are a list. [...]
> 
> Well, in some sense I suppose, but technically, actually not
> so:
> 
> (listp (defun dummy-function ()
>          (message "darn good software") )) ; nil

That is tricky question.

Anything or nothing between parenthesis is a list.

That it is TRUE that nothing between parenthesis is something, in this
case a list is proven by your similar example of yours:

(listp ()) => t

That sometimes something which is not nothing between the list cannot
be list is proven by your own example:

(listp (defun dummy-function ()
          (message "darn good software"))) => nil

So nothing is a list but something in that list becomes sometimes not a list.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> 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.

>>> AFAIU, this is also how the author of Magit understands that
>>> guideline: Magit binds three keys globally unless 
>>> magit-define-global-key-bindings, whose default value is t, has
>>> been set to nil, and only recommends in the docstring to bind "C-c
>>> g". With your understanding of the guideline, Magit could have
>>> added a third possible to magit-define-global-key-bindings, say
>>> 'best, with which the "C-c g" binding would have been created
>>> automatically.
>>
>> No, because the user is not asked, and I have to add extra
>> configuration, to prevent Magit from changing my environment.
>
> The point here is that the three values for
> magit-define-global-key-bindings would have resulted in three
> behaviors: nil => do not bind any key, t => bind keys but not in C-c,
> 'best => bind keys including one in C-c.  The author of Magit did not
> do this, so my guess (it's just a guess, I could be wrong) is that he
> also has a literal interpretation of the guideline.

The way I see it is that there is no need for a value like 'best,
because this whole idea is that magit wants to bind their keys by
default, but it shouldn't bind it to C-c g. If you're going to set
magit-define-global-key-bindings to 'best, you might just as well
directly bind magit-status to C-c g. I think it would be totally ok for
Magit to have the default value set to nil, and then bind to C-c g, but
that undermines their entire motivation, as there would be no default
binding.

Btw., are there any other examples of packages binding global keys by
default?
 
-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Jean Louis]

* Philip Kaludercic <philipk@posteo.net> [2021-02-13 23:15]:
> Btw., are there any other examples of packages binding global keys by
> default?

Searching through my ~/.emacs.d/elpa:

./keychain-environment-20180318.2223/all-the-icons-ivy-rich-20200830.1745.el\0641:
(global-set-key [remap kill-buffer]
#'all-the-icons-ivy-rich-kill-buffer)

./keychain-environment-20180318.2223/better-defaults-20200717.2012.el\071:
(global-set-key (kbd "C-x C-b") 'ibuffer)

etc.

./company-0.9.13/company-autoloads.el\0370:  (global-set-key (kbd \"C-c y\") \\='company-yasnippet)
./company-0.9.13/company-yasnippet.el\0151:  (global-set-key (kbd \"C-c y\") \\='company-yasnippet)

./info+-0/info+.el\02876:(global-set-key [remap info-emacs-manual]
'info-manual) ; `C-h r'

./winring-20180530.18/winring.el\0532:  (global-set-key winring-keymap-prefix winring-map))
./issn-verify-1.0.0/iscroll.el\0298:        (global-set-key [remap next-line] #'iscroll-next-line)
./issn-verify-1.0.0/iscroll.el\0299:        (global-set-key [remap previous-line]
./issn-verify-1.0.0/iscroll.el\0303:    (global-set-key [remap next-line] nil)
./issn-verify-1.0.0/iscroll.el\0304:    (global-set-key [remap previous-line] nil)))

Those are remappings but still..

./gnuplot-20200322.53/gnuplot-autoloads.el\075:     (global-set-key [(f10)] 'gnuplot-make-buffer)" t nil)
./gnuplot-20200322.53/gnuplot.el\0136:;;   (global-set-key [(f9)] 'gnuplot-make-buffer)

Then exwm but that should be natural for exwm.

In general, not many. More of them just suggest global bindings in
their comments.

Jean

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>>> 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.

>
> The way I see it is that there is no need for a value like 'best, 
> because this whole idea is that magit wants to bind their keys by 
> default, but it shouldn't bind it to C-c g. If you're going to set 
> magit-define-global-key-bindings to 'best, you might just as well 
> directly bind magit-status to C-c g. I think it would be totally ok for 
> Magit to have the default value set to nil, and then bind to C-c g, but 
> that undermines their entire motivation, as there would be no default 
> binding.
>

Do you use Magit?  Magit binds three commands globally when 
magit-define-global-key-bindings is t (its default value): magit-status to 
C-x g, magit-dispatch to C-x M-g, and magit-file-dispatch to C-c M-g. 
Magit recommends to rebind the last one (magit-file-dispatch) to C-c g, 
and there is no special value for magit-define-global-key-bindings, and no 
code elsewhere in Magit, to do that automatically.

>
> Btw., are there any other examples of packages binding global keys by 
> default?
>

There are indeed (for example Drew's packages), but even if there were 
none, that wouldn't change anything, because there are lots and lots of 
packages that recommend their users to install such global bindings 
manually.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>>> 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.

I agree. I was thinking about asking emacs-devel for opinions on the
matter, that will probably make more sense, and might result in a
rephrasing.

>> The way I see it is that there is no need for a value like 'best,
>> because this whole idea is that magit wants to bind their keys by 
>> default, but it shouldn't bind it to C-c g. If you're going to set
>> magit-define-global-key-bindings to 'best, you might just as well 
>> directly bind magit-status to C-c g. I think it would be totally ok
>> for Magit to have the default value set to nil, and then bind to C-c
>> g, but that undermines their entire motivation, as there would be no
>> default binding.
>
> Do you use Magit?  Magit binds three commands globally when
> magit-define-global-key-bindings is t (its default value):
> magit-status to C-x g, magit-dispatch to C-x M-g, and
> magit-file-dispatch to C-c M-g. Magit recommends to rebind the last
> one (magit-file-dispatch) to C-c g, and there is no special value for
> magit-define-global-key-bindings, and no code elsewhere in Magit, to
> do that automatically.

I use MELPA Stable, so my version of Magit is from 2018, so the only one
I use magit-status.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

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

[Jean Louis]

* 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.

Count all the combinations. It is far far more than 26 combinations. I
find that problem is already solved, just collisions with other key
bindings could be solved by built-in Emacs function where then third
party package invokes the built-in Emacs function to customize the
prefix for the package.

User then decides either to replace some already bound key or to use
some of the free keys. That is why we have programming and computer to
help us decide. Reading comments in packages or READMEs is one way,
but computer assisted decision is smarter way. We can use artificial
intelligence and `key-binding' function as help.

What I wonder is WHY is only one key suggested to be re-purposed? I
cannot see solution there, just more conflicts as then all packages
are going into one key.

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

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]

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. So I get that there
might not be that many commands, but I'd dare to claim that 52 keys are
a fair number. This is not a matter of computational power or memory,
the needs are not increasing exponentially over time. Keyboards have
stayed more or less the same for over 70 years now and mouses have
rarely more than three buttons. Even with Emacs, I am fairly sure that
if you'd follow what commands and keys most people use, there would be
an uneven/exponential distribution for everyone (while
self-insert-command, yank, switch-to-buffer, ... are more common,
open-line, back-to-indentation, forward/backward-page might differ a lot
more and other commands that are bound by default are probably
completely ignored), that might even be unique (e.g. I've recently
noticed I unconsciously use find-alternate-file as a kind of
revert-buffer).

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.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

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

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> There are no package authors except of Drew, who asked for
> "some key" to be re-purposed for their specific package.

???

Everyone here who ever wrote more than 100 posts here is
a package author, almost. Here are my 8. (Should perhaps be
modernized, some of them.)

  https://dataswamp.org/~incal/emacs-packs/

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

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

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-14 09:34]:
> Jean Louis wrote:
> 
> > There are no package authors except of Drew, who asked for
> > "some key" to be re-purposed for their specific package.
> 
> ???
> 
> Everyone here who ever wrote more than 100 posts here is
> a package author, almost. Here are my 8. (Should perhaps be
> modernized, some of them.)
> 
>   https://dataswamp.org/~incal/emacs-packs/

Sure, but did you ask for re-purposiation?

Do your packages have need for global-set-key?

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

[Drew Adams]

(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.

Before that general request, I asked that the
unbound (by default) prefix key `C-x p' NOT
suddenly be bound by Emacs by default.  To no
avail - my polite plea was ignored.

I later asked that the unbound (by default)
key `C-x x' NOT be bound by Emacs by default.
To no avail - my plea was ignored.

It was only recently that I asked more generally
that (barring discussion followed by exceptional
maintainer decision) _NO_ new keys be bound by
Emacs by default - we should have a moratorium
on doing that.  To no avail, so far.

> There was no real problem in the first place as
> there was no contradictory forces against each other.

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.

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.

> packages anyway can re-purpose keys without asking
> Emacs development team.

Sure, 3rd-party code _can_ do anything, without
regard to anyone else.  We're talking about GNU
Emacs key-binding _conventions_: rules for
playing well together.

It's much more constraining on 3rd-party code
when Emacs itself binds a key by default, than
when some other 3rd-party code binds the same
key by default.  This has all been explained,
with good arguments.  No one has argued to the
contrary.  When Emacs itself does something
like that, it changes the game for everyone.

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.

(That is, do that if you're really interested
in the question/problem.  If you're not, then
don't bother.  But please don't just repeat
questions or arguments here that have already
been made in the more general discussion.)

Again, it's not I who spread this discussion
from bug threads to emacs-devel, or to this
user help list.

Raising the discussion on emacs-devel was a
_good_ thing.  But there's little sense in
ignoring what's already been said, and
starting over again here.  Everyone's welcome
to add their voice in any way to the existing
discussion.  But please _add_, cognizant of
what's already been said.

> 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.

I was the one who brought up the problem, yes.
But I brought it up in the context of bug
discussions where new default key-binding
actions were being discussed.  Yes, I objected
to those proposed actions.

Had the initial grabbing of a prefix key for
Project chosen a key that I wasn't already
using for (many) Bookmark+ commands, it's
unlikely I would have said anything.

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.

Or perhaps because the request was from me
(?) - the reason given was just that Emacs
dev is under no "obligation" to respect
such a request, which is of course true
and uncontested - no obligation.  But some
consideration would have been nice.

It was not even I who took the discussion
from bug threads to emacs-devel.  So no,
I'm not the only person who recognizes the
problem.

> 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.

This is a false dichotomy.  Use of any 3rd
party code is optional.  No one's forced to
load any library.  Everyone agrees that in
general, when it makes sense, it's more
polite for just loading a library not to
change Emacs session state (beyond loading
definitions etc.).

But there are all kinds of 3rd-party code.
There's little real difference between adding
a keymap & providing a command to activate it,
and just activating it by default, provided
doc or commentary makes clear what happens.

I have code that does one and code that does
the other.  And I have code that just suggests
key bindings, in comments.  In general, more
important and larger libraries, with more
users, need to be handled more carefully. 

It's important to understand the reasons
behind any convention - the context and
scope for its action.

Consider, for example, the convention that
functions (including commands) shouldn't
change or bind user option values.

Emacs itself provides functions and commands
that do just that.  Otherwise there would be
no way to do it!

Does that (good, reasonable) convention mean
that 3rd-party code should never provide
commands, menus, UI's, etc. that users can
use to change option values, face values,
etc.?  Of course not.

And yes, I have code that provides such
UI's, e.g., code that lets you tweak face
values incrementally, showing the effect
as you do so.  And I have code that helps
improve the Customize UI.

There's no rule against improving Emacs by
offering such things - that would be absurd.
(And the conventions apply to Emacs's own
code also, not just to 3rd-party code.)

That convention is only a general guideline,
which points out that it makes no sense, and
it can be impolite, usually, for 3rd-party
code to change preferences that a user has
set.  But such a rule clearly doesn't apply
to code whose very purpose is to help a
use choose and set such preferences.

This _should_ be obvious.  But even Emacs
developers (misguidedly, IMO) shy away from
_binding_ user options within a function,
even if the purpose of the function involves
temporarily using a different value.  To me
that's misunderstanding, taking the guideline
as a hard-&-fast rule, and not understanding
the logic behind it.

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

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> 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 even more so, as that would imply quite possibly million,
maybe billion imaginary functions!

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

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

[Drew Adams]

> > 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.

I disagree.

> > [Users] are welcome to do anything, and the
> > conventions explicitly say so.
> 
> Even third parties are welcome to do anything.

No.  The conventions reserve some keys for users,
some keys for major modes, and some keys for
minor modes.  "Reserved" means that if you follow
the convention then you don't use those, except
as a user, or for a major mode, or for a minor mode.

> What repercussion is there for third party if they actually break the
> convention?

If you don't play well with the others in the sand
box you might find yourself on the receiving end.

The conventions are there as guidelines to good,
social behavior.  No, there is no key-binding
Gestapo that will grab you out of your bed and
haul you away.  So what?

> 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.

You do that, if you like.  I don't.

You can get away with driving at 230 km/hr on a
highway in France - they have limited real traffic
control.  That doesn't make such behavior smart or
civilized.

> 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.

No, key-binding conflicts, just like name conflicts,
are a practical problem.  That's why we have key
binding conventions, to avoid conflicts.

For names, Elisp at least has the possibility of
using additional obarrys.  But that's quite limited,
in practice.  Common Lisp has its "packages", which
are a bit like XML namespaces.  For key bindings
Elisp has only polite conventions.  And those work
well enough, in practice.  (They can't deal with an
Emacs that is fast developing the remaining free
territory, however.)

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>> 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.
>
> I disagree.

I don't know if I disagree or agree, but note that it isn't
just a matter of the number of theoretical keybindings, it is
also what keybindings are ergonomic, short, close to asdf jkl;
(i.e. fast) perhaps mnemonic (tho that shouldn't be
over-emphasized, particularly not for stuff that is used
often, as that will bypass the brain pretty soon anyway and
enter muscle memory) and such concerns.

Good keybindings are not infinite.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

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

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2021-02-15 02:30]:
> > 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.
> 
> You do that, if you like.  I don't.

I have not written that above sentence correctly. What I wanted to say
is that third party packages do not break the convention and mostly
how I have shortly analyzed it, do not set globally keys.

They mostly will advise users to set global keys.

While they are free, they don't do that.

> > 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.
> 
> No, key-binding conflicts, just like name conflicts,
> are a practical problem.  That's why we have key
> binding conventions, to avoid conflicts.

OK and where is the actual problem?

Can we define it?

I can see that some packages would recommend same key bindings on
conflicting keys, but that is not necessarily a problem, because there
are no people telling that they have conflict with it.

Conflicting keys are not necessarily conflict for the person.

For example can you tell me which key from which package collides with
other key in other package AND that it becomes a problem or conflict?

Person complaining please stand up.

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

[Gregory Heytings]

>
> So I get that there might not be that many commands, but I'd dare to 
> claim that 52 keys are a fair number. This is not a matter of 
> computational power or memory, the needs are not increasing 
> exponentially over time.
>
> [...]
>
> 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.
>

On Elpa and Melpa there are currently 5121 distinct packages.  And there 
are lots of packages that are not on Elpa and/or Melpa.  That number can 
only grow over time, perhaps not exponentially, but grow nonetheless. 
Emacs itself has lots and lots of commands bound to keys, I don't know the 
exact number, but it's surely an order of magniture larger than 52. 
"Starter kits" such as Spacemacs include 100 or more external packages. 
Or course not all of them would have a reason to bind command globally, 
but some will bind more than one command.  So it seems to me that the 52 
keys limit is easy to reach.

I agree with Drew that the solution you propose is not user-friendly, 
because querying a user who doesn't yet know how a package works and what 
its commands are to bind some commands they do not yet know to a key is 
confusing.  What users would most likely do is to answer "yes" everywhere 
without thinking further.  (It reminds me what Windows program installers 
did when I started using computers, about 25 years ago.  They asked you a 
few questions, I don't remember precisely what they were, but it was 
something like "where do you want to install the program?", "do you want 
to put a shortcut on the desktop?", "do you want to put a shortcut in the 
start menu?".  You read those questions when you installed your first 
program, because you thought they were important, but later you just 
clicked "yes" to every question.)

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

Gregory Heytings wrote:

> On Elpa and Melpa there are currently 5121 distinct packages [...]

We could reduce the code size a lot if we did huge package
libraries and organized everything systematically, with search
tools and stuff, optimally...

Below is just some Elisp that comes to mind. How many people
did that, in how many different but similar versions and
varieties, instead of getting it somewhere?

I still don't know where to look and installation is more
difficult than writing it even if I were to find it.

Bring all simple things into a bunch of huge files, done deal.

(defun // (n d)
  (/ n d 1.0) )
;; (// 8 256) ; 0.03125
;; (/  8 256) ; 0

(defun percent (n d)
  (let ((pct (/ n d 0.01)))
    (message "%.1f%%" pct)))
;; (percent 8  256) ; 3.1%
;; (percent 0 1337) ; 0.0%

(defun mean-value (vs)
  (let*((sum  (apply #'+ vs))
        (mean (/ sum (length vs) 1.0)) )
    mean) )

(defun hypotenuse (c1 c2)
  (sqrt (+ (* c1 c1) (* c2 c2))) )

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

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

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 2583 bytes --]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> So I get that there might not be that many commands, but I'd dare to
>> claim that 52 keys are a fair number. This is not a matter of 
>> computational power or memory, the needs are not increasing
>> exponentially over time.
>>
>> [...]
>>
>> 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.
>
> On Elpa and Melpa there are currently 5121 distinct packages.  And
> there are lots of packages that are not on Elpa and/or Melpa.  That
> number can only grow over time, perhaps not exponentially, but grow
> nonetheless. Emacs itself has lots and lots of commands bound to keys,
> I don't know the exact number, but it's surely an order of magniture
> larger than 52. "Starter kits" such as Spacemacs include 100 or more
> external packages. Or course not all of them would have a reason to
> bind command globally, but some will bind more than one command.  So
> it seems to me that the 52 keys limit is easy to reach.

I'm not sure that the number of published packages necessarily means
that 1. user install more packages over time 2. some fixed proportion of
these require global bindings. More often than not, packages might just
provide hooks or implement interfaces like Xref or CAPF, thus avoiding
their own special keys.

> I agree with Drew that the solution you propose is not user-friendly,
> because querying a user who doesn't yet know how a package works and
> what its commands are to bind some commands they do not yet know to a
> key is confusing.  What users would most likely do is to answer "yes"
> everywhere without thinking further.  (It reminds me what Windows
> program installers did when I started using computers, about 25 years
> ago.  They asked you a few questions, I don't remember precisely what
> they were, but it was something like "where do you want to install the
> program?", "do you want to put a shortcut on the desktop?", "do you
> want to put a shortcut in the start menu?".  You read those questions
> when you installed your first program, because you thought they were
> important, but later you just clicked "yes" to every question.)

That is why ideally each suggestion should be accompanied by an
explanation, and keep the number of suggestions to a minimum. But this
can be discussed when I come around to actually implementing the idea,
and sending it to emacs-devel.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

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

[Gregory Heytings]

>
> I'm not sure that the number of published packages necessarily means 
> that 1. user install more packages over time 2. some fixed proportion of 
> these require global bindings. More often than not, packages might just 
> provide hooks or implement interfaces like Xref or CAPF, thus avoiding 
> their own special keys.
>

Frankly, I don't understand why it is necessary to argue so much to 
explain that a limit of 26 or 52 global bindings is not enough.  It's as 
if your operating system forced you to have at most 26 or 52 files or 
folders in each folder; of course it would be feasible to use such an 
operating system, but it would be terribly impractical.  I see that, out 
of the ~11K commands in Emacs core, there are currently ~450-500 commands 
bound to keys in global-map (counting only the C-something, M-something 
and C-M-something).  I or you may, today, not need more than 26 or 52 
global bindings for external packages, we may perhaps only need 10 or 20, 
but this discussion isn't about me or you, or about the current situation, 
it's about finding a long-term solution to a problem, with the hope that 
in the long term more and more external packages will be useful to a large 
audience.  It's about making Emacs friendlier for beginners, and also for 
third-party library developers by giving them a "home" in Emacs' default 
keyboard bindings.

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

Gregory Heytings wrote:

> Frankly, I don't understand why it is necessary to argue so
> much [...]

Absolutely positively, it isn't necessary by any means.
The only reason to do it is if you enjoy it.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

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

[Robert Thorpe]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> I'm not sure that the number of published packages necessarily means 
>> that 1. user install more packages over time 2. some fixed proportion of 
>> these require global bindings. More often than not, packages might just 
>> provide hooks or implement interfaces like Xref or CAPF, thus avoiding 
>> their own special keys.
>>
>
> Frankly, I don't understand why it is necessary to argue so much to 
> explain that a limit of 26 or 52 global bindings is not enough.  It's as 
> if your operating system forced you to have at most 26 or 52 files or 
> folders in each folder; of course it would be feasible to use such an 
> operating system, but it would be terribly impractical.  I see that, out 
> of the ~11K commands in Emacs core, there are currently ~450-500 commands 
> bound to keys in global-map (counting only the C-something, M-something 
> and C-M-something).  I or you may, today, not need more than 26 or 52 
> global bindings for external packages, we may perhaps only need 10 or 20, 
> but this discussion isn't about me or you, or about the current situation, 
> it's about finding a long-term solution to a problem, with the hope that 
> in the long term more and more external packages will be useful to a large 
> audience.  It's about making Emacs friendlier for beginners, and also for 
> third-party library developers by giving them a "home" in Emacs' default 
> keyboard bindings.

I'm not sure I understand your point here.  Any single key that's picked
will have a similar limitation.

For example, let's suppose that M-o is picked.  That's my favourite, I
know you don't like it.  In that case any key can follow it.  That gives
the entire keyboard, maybe 100 keys.  Is that so different to 52?

Also, nested prefix keys can be used.  For example suppose that Magit
uses C-c g as a prefix.  It can then be followed by any keyboard
character.

However, I agree with you that adding things to the users space in the
C-c prefix is not ideal.  Adding another prefix key for 3rd-parties
would be better.  Assuming, of-course, that Drew Adam's proposal of a
moratorium is off-the-table.

BR,
Robert Thorpe

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

[Gregory Heytings]

>
> I'm not sure I understand your point here.  Any single key that's picked 
> will have a similar limitation.
>

With a single key you indeed have a limitation, but it's the limitation of 
the keyboard, not an arbirary one.  You have full access to all letters, 
all digits, all symbols, combined or not with the control and/or meta 
modifier.  That's a lot more than 26 or 52 keys.

>
> For example, let's suppose that M-o is picked.  That's my favourite, I 
> know you don't like it.
>

It's in the proposal, it would be a perfect choice, together with C-o.

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

[Robert Thorpe]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> I'm not sure I understand your point here.  Any single key that's picked 
>> will have a similar limitation.
>>
>
> With a single key you indeed have a limitation, but it's the limitation of 
> the keyboard, not an arbirary one.  You have full access to all letters, 
> all digits, all symbols, combined or not with the control and/or meta 
> modifier.  That's a lot more than 26 or 52 keys.

I see what you mean but I don't think it's a huge difference.  Most
desktop keyboards have ~104 keys.  And some of those can't be
differentiated from each other by Emacs.  Laptop keyboards usually have
fewer, mine has 81.

>> For example, let's suppose that M-o is picked.  That's my favourite, I 
>> know you don't like it.
>>
>
> It's in the proposal, it would be a perfect choice, together with C-o.

I think C-o is a terrible idea.  Open-line is a very useful command.
It's useful in all sorts of text editing scenarios.  Yes, the same can
be done using return and C-b, but that's longer.

In my opinion, M-o is a good idea though.  The M-o prefix is only really
useful in enriched mode.  Perhaps it could be retained in that mode
only.

BR,
Robert Thorpe

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

[Gregory Heytings]

>>> I'm not sure I understand your point here.  Any single key that's 
>>> picked will have a similar limitation.
>>
>> With a single key you indeed have a limitation, but it's the limitation 
>> of the keyboard, not an arbirary one.  You have full access to all 
>> letters, all digits, all symbols, combined or not with the control 
>> and/or meta modifier.  That's a lot more than 26 or 52 keys.
>
> I see what you mean but I don't think it's a huge difference.  Most 
> desktop keyboards have ~104 keys.  And some of those can't be 
> differentiated from each other by Emacs.  Laptop keyboards usually have 
> fewer, mine has 81.
>

Indeed, and when you combine these with the control and/or meta and/or 
shift modifier you have ~400 possible keys.  Which means that with two 
prefix keys you have ~800 possible keys.

The main point is that third-party packages are first-class citizens and 
should get all possible keys, not an arbitrary subset.

>>> For example, let's suppose that M-o is picked.  That's my favourite, I 
>>> know you don't like it.
>>
>> It's in the proposal, it would be a perfect choice, together with C-o.
>
> I think C-o is a terrible idea.  Open-line is a very useful command.
>

The proposal explicitly mentions that open-line would remain bound to C-o 
C-o.  That's three key presses instead of two.  And if you think that 
open-line is so important in your workflow that pressing three keys 
instead of two is really not possible, you can of course always bind 
open-line to C-o in your init file, and move the third-party library 
keymap that would be on C-o somewhere else.

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

[Drew Adams]

> I agree with Drew that the solution you propose is not user-friendly,

Huh?  AFAIK, I've said nothing about what you guys
seem to be talking about now.  Please cite what
you think I said about this, if you're going to
make references to what I've said.

Perhaps you're confusing me with someone else,
wrt this point?  There are so many messages, and
the subject seems to careen wildly without the
Subject line changing, that I, at least, have
trouble following (especially since much of
what's said doesn't hold much interest for me).

> because querying a user who doesn't yet know how
> a package works and what its commands are to bind
> some commands they do not yet know to a key is
> confusing.

That's true, in general, though a query/prompt
can make things clear.  It can even pop up doc
etc. to make things clear.  I'm not saying
anything about how appropriate such querying
might be.  It might be inefficient, inappropriate,
or even downright annoying.

I, for one, think that users are well served
by taking the initiative to read something
about a package, command, or whatever before
starting to load or use it.  That's just my
advice.

In the "old days" user read the Commentary in
a library before using it.  And wise users even
looked at the code, at least as a sanity check.

Nowadays, I get the impression that many users
just load a package and give it a try, with no
regard to help/doc the author has provided, and
no concern or curiosity about the code (what it
does, how it does it, security, etc.).

> What users would most likely do is to answer
> "yes" everywhere without thinking further.

Yup.  Laziness, mostly, I guess.  Or blind
faith, perhaps.

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

[Gregory Heytings]

>> I agree with Drew that the solution you propose is not user-friendly,
>
> Huh?  AFAIK, I've said nothing about what you guys seem to be talking 
> about now.  Please cite what you think I said about this, if you're 
> going to make references to what I've said.
>

See:

Date: Sat, 13 Feb 2021 20:48:11 +0000
Message-ID: <SA2PR10MB4474A5DC64E0BF9FCF3C44D6F38A9@SA2PR10MB4474.namprd10.prod.outlook.com>

in which you said:

>> Philip Kaludercic suggested some code for prompting users before 
>> mapping keys.  I think that's a good idea.
>
> Maybe that could be part of a solution.  But many users will not 
> appreciate, or not be prepared for, making such key-binding decisions at 
> the outset and on the fly.
>

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

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-14 21:58]:
> 
> > > I agree with Drew that the solution you propose is not user-friendly,
> > 
> > Huh?  AFAIK, I've said nothing about what you guys seem to be talking
> > about now.  Please cite what you think I said about this, if you're
> > going to make references to what I've said.
> > 
> 
> See:
> 
> Date: Sat, 13 Feb 2021 20:48:11 +0000
> Message-ID: <SA2PR10MB4474A5DC64E0BF9FCF3C44D6F38A9@SA2PR10MB4474.namprd10.prod.outlook.com>
> 
> in which you said:
> 
> > > Philip Kaludercic suggested some code for prompting users before
> > > mapping keys.  I think that's a good idea.
> > 
> > Maybe that could be part of a solution.  But many users will not
> > appreciate, or not be prepared for, making such key-binding decisions at
> > the outset and on the fly.

It can be easily solved by introducing variable
`ask-me-for-packages-which-need-prefix-key' which is by default NIL.

Packages can then notify Emacs that they need one or more prefix keys:

(need-prefix-key 'my-package-map-1)
(need-prefix-key 'my-package-map-2)

Emacs would then provide the unified wizard function that asks those
users who have set the above variable for prefix keys for the package.

That solves universally those hypothetical problems discussed.

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> It can be easily solved by introducing variable
> `ask-me-for-packages-which-need-prefix-key' which is by
> default NIL.
>
> Packages can then notify Emacs that they need one or more
> prefix keys:
>
> (need-prefix-key 'my-package-map-1)
> (need-prefix-key 'my-package-map-2)
>
> Emacs would then provide the unified wizard function that
> asks those users who have set the above variable for prefix
> keys for the package.
>
> That solves universally those hypothetical
> problems discussed.

A hypothetical solution - to solve a hypothetical problem.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

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

[Drew Adams]

> >> I agree with Drew that the solution you propose is not user-
> friendly,
> >
> > Huh?  AFAIK, I've said nothing about what you guys seem to be talking
> > about now.  Please cite what you think I said about this, if you're
> > going to make references to what I've said.
> 
> See:
> Date: Sat, 13 Feb 2021 20:48:11 +0000
> Message-ID:
> <SA2PR10MB4474A5DC64E0BF9FCF3C44D6F38A9@SA2PR10MB4474.namprd10.prod.out
> look.com>

Please provide a URL next time.  I don't know how
(or care to know how) to find the message using
such an incantation.

> in which you said:
> 
> >> Philip Kaludercic suggested some code for prompting users before
> >> mapping keys.  I think that's a good idea.
> >
> > Maybe that could be part of a solution.  But many users will not
> > appreciate, or not be prepared for, making such key-binding decisions
> > at the outset and on the fly.

Guilty as charged, I guess (haven't seen the context).

But I don't say that that is "not user-friendly".
I was saying that as it was presented it has
limited appeal - it might be made _part_ of a
workable solution; dunno.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-13 11:34]:
> 
> > > To me what you propose looks pretty close to using customize to set
> > > a foobar-set-global-binding variable that would be used in a call to
> > > global-set-key.
> > 
> > Yes, that could also be done, the precise code that is generated is an
> > open question
> > 
> 
> But that would be forbidden by the guideline "Don't define 'C-c LETTER' as a
> key in Lisp programs", wouldn't it?

I think not, as that would not be automated global setting by the
package. User have got the control, user decided, not the package.

> (defcustom foobar-global-key "" "Foobar global key in C-c")
> ...
> (if (length foobar-global-key)
>   (global-set-key (kbd (concat "C-c " foobar-global-key)
> 'foobar-foo-command)))

I would rather keep that without C-c and just let user decide on the
prefix key which could be any. By inspecting already bound key, user
could by trial and error in the wizard choose other rater by user
unused key as prefix for the package.

Like this:

1. This program uses key bindings.

2. You will be asked to assign a prefix key for key bindings in this
   package.

3. We recommend that you assign C-c ANY-LETTER as a prefix key, but
   you may as well choose Super in combination with ANY-LETTER or M
   (Alternative) and so on. Please press the key that you think it
   could be prefix to this package's commands.

4. You have pressed C-x ; that is bound to `comment-set-column'. If
   you now accept C-x ; as prefix for package X, that command will not
   be available on that key any more. Are you sure? Yes or no?

   If not sure, we may recommend that you use C-c ; as prefix for this
   package, would that be fine?

   Continue the loop.

5. Thank you. Your prefix has been set on Super key and letter p. You
   may change "s-p" at any time in future to other prefix by invoking
   function M-x key-wizard-of-oz-for-package-X or by customizing the
   variable `package-X-prefix-key'

The function to assign the prefix key for a package could become Emacs
function so that any new package uses that function to assign the
prefix key for the package or to assign some keys for commands that
are not prefix keys. 

> > But even considering that, what do you think that the long-term issue
> > is? Do you think that with time, people will be using more and more
> > packages that need global keys?
> 
> I do not think, I see.  Just have a look at the starter kits, or at the init
> files of those who make them public.  You'll see that there are many
> packages that need global keys.

Let us have some names of packages to look at it.

Jean

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [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

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> 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 [...]
>
> 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.

Unheard of.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-13 15:45]:
> > For example none of Super key bindings is used by Emacs.
> > That makes alone possibly 7000-10000 possible combinations.
> 
> Unheard of.

How about trying it?

If s-a is prefix key, 26 letters + 26 upper case letters + 10 numbers
plus 32 symbols on my keyboard is 94 combinations multiplied by 94
possible other following keys, not counting possible middle suffix
keys, yields ations is 8836 possible bindings with Super key on this
keyboard.

Make s-a prefix key:

s-a a
s-a b
s-a 1
s-a 2
s-a !
etc.

Make s-A prefix key:

s-A a
s-A b
s-A 1
s-A 2
s-A !
etc.

Then continue for each key as prefix key and multiply by other
combinations. I think 8836 minimum is here. International keyboards
could have more than that.

Example binding that works:

(global-set-key (kbd "s-U u") (lambda () (interactive) (message "Hello")))

Then if we add combinations with Control on my keyboard that becomes
94 x 94 x 94 with Control, so there are 830584 possible key bindings
by using Super key and Super combined with Control key.

Example binding:

(global-set-key (kbd "C-s-b i") (lambda () (interactive) (message "Hello")))

Super can be combined with Meta or Alternative key. So that adds
another multiplication by 94 and we end up with 78,074,896 possible
key bindings that use Super key.

Example bindings:

(global-set-key (kbd "M-s-b b") (lambda () (interactive) (message "Hello")))

(global-set-key (kbd "M-s-b C-s-c") (lambda () (interactive) (message "Hello")))

(global-set-key (kbd "M-s-b M-s-7") (lambda () (interactive) (message "Hello")))

If we then make the second key also prefix the number of possible
bindings grows and grows.

If my calculation is wrong, then please make your own calculation and
make cross checks to verify it and post it here.

As currently we have situation that some people will say that Super
often collides with Window Manager, but is that often more than 94
combinations by 94 combinations?

If s-p collides then maybe s-; does not. If s-; is prefix key that
alone opens 94 possible combinations on this keyboard. If I wish I
could use a middle prefix key in that combination and get 8836
combinations.

Example where s-; a is prefix key:

(global-set-key (kbd "s-; a 1") (lambda () (interactive) (message "Hello")))
(global-set-key (kbd "s-; a 2") (lambda () (interactive) (message "Hello")))
(global-set-key (kbd "s-; a 3") (lambda () (interactive) (message "Hello")))
(global-set-key (kbd "s-; b 1") (lambda () (interactive) (message "Hello")))
(global-set-key (kbd "s-; B 1") (lambda () (interactive) (message "Hello there")))

The demonstration is there to show that combinations are more or less
endless. I have no problem using s-; B 1 or remembering it. It is
nothing less usable than C-x 5 0 or similar known commands.

C-x 8 ' U gives me in Emacs = Ú -- so if I need that I will
remember. I often use C-x 8 L to specify pounds as money symbol like
£200 and I remember it. Personally I use C-x 7 as prefix for years
already. C-x 9 is also free.

Problem is in console, but maybe that problem can be solved. What you
think how to solve Super key in console? Maybe kernel developers need
to be contacted?

We justdid not find how. That it can be solved is already clear as
Super does work in X, so detection will work in console but it could
be that it was tradiitonally just forgotten. Virtually all users have
today Super key. If they change it in kernel then Super key becomes
really super.

Jean

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> If s-a is prefix key, 26 letters + 26 upper case letters +
> 10 numbers plus 32 symbols on my keyboard is 94 combinations
> multiplied by 94 possible other following keys, not counting
> possible middle suffix keys, yields ations is 8836 possible
> bindings with Super key on this keyboard.

Are you trying to compute the total number of keybindings?

What do you mean by "middle suffix keys"?

What is the Super key? A modifier like C and M? Here are
a bunch of standards:

  https://en.wikipedia.org/wiki/ISO/IEC_9995

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-13 18:10]:
> Jean Louis wrote:
> 
> > If s-a is prefix key, 26 letters + 26 upper case letters +
> > 10 numbers plus 32 symbols on my keyboard is 94 combinations
> > multiplied by 94 possible other following keys, not counting
> > possible middle suffix keys, yields ations is 8836 possible
> > bindings with Super key on this keyboard.
> 
> Are you trying to compute the total number of keybindings?
> 
> What do you mean by "middle suffix keys"?

That was mistake, sharp-eye. I was meaning prefix after prefix.

When s-p is prefix one can make s-p p also prefix, that increases
rapidly number of available keys. I favor prefixes like

MODIFIER-LETTER SAME-LETTER-AGAIN as such can be invoked quicker.

> What is the Super key? A modifier like C and M? Here are
> a bunch of standards:
> 
>   https://en.wikipedia.org/wiki/ISO/IEC_9995

Solution to make Super key work in console shall be
practical. Do you have more specific reference?

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> When s-p is prefix one can make s-p p also prefix, that
> increases rapidly number of available keys. I favor prefixes
> like

Suggestion, start with: what are the number of keybindings if
there are no additional prefix keys defined, with modifiers are
C and M?

> MODIFIER-LETTER SAME-LETTER-AGAIN as such can be
> invoked quicker.

Well, for the first and most important one, sure. Then the
asdf jkl; keys as they are close and fast and ergonomic, then
the ... etc

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-02-13 18:39]:
> Jean Louis wrote:
> 
> > When s-p is prefix one can make s-p p also prefix, that
> > increases rapidly number of available keys. I favor prefixes
> > like
> 
> Suggestion, start with: what are the number of keybindings if
> there are no additional prefix keys defined, with modifiers are
> C and M?

So just to count number of keys without using those keys as prefix
keys?

And then just one shall be reserved for third party packages? And not
as prefix?

Is that what was meant with it?

Those third party packages may start fighting for that one reserved
key.

> > MODIFIER-LETTER SAME-LETTER-AGAIN as such can be
> > invoked quicker.
> 
> Well, for the first and most important one, sure. Then the
> asdf jkl; keys as they are close and fast and ergonomic, then
> the ... etc

In modal mode Emacs offers probably better keybindings like Xah
explained: https://github.com/xahlee/xah-fly-keys

We still think that the key need be reserved, but we forgot the
growing number of vi-like users who prefer modal system. 

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Robert Thorpe]

"Philip K." <philipk@posteo.net> writes:

> [1:text/plain Hide]
>
> Gregory Heytings <gregory@heytings.org> writes:
>
...
>> That reminds me the famous "640 kb should be enough for anyone" ;-)
>> Indeed, 26 letters is not enough.  Magit has three global commands, 
>> Org-mode has three, and Bookmark+ has three keymaps.  With just three
>> packages you've already used 35% of the available keys.  I hope you 
>> understand that it can't be a long-term solution.  Moreover, AFAIU,
>> packages cannot automatically bind their commands to C-c LETTER keys 
>> anyway: these keys are strictly reserved for users in their personal
>> configuration files.
>
> I think that's the pessimistic way to look at it, the optimistic one
> would be to say that you only need 35% of the key-space. I don't have a
> feeling for how many global keys people bind by default, one would have
> to study public configurations to find out. But I still remain sceptical
> that -- compared to memory usage -- that need for keys is rising that
> much.

Remember prefix keys here.  A user can define a prefix key anywhere in
the region reserved for users.

The manual says:

"A small number of keys are reserved for user-defined bindings, and
should not be used by modes, so key bindings using those keys are safer
in this regard.  The reserved key sequences are those consisting of
‘C-c’ followed by a letter (either upper or lower case), and function
keys <F5> through <F9> without modifiers (*note Modifier Keys::)."

It does not ban using those keys as prefixes.  I can make <F9> a prefix,
then I have the full keyboard to play with once again once I've pressed
F9.

BR,
Robert Thorpe

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Philip K.]

[-- Attachment #1: Type: text/plain, Size: 2272 bytes --]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> "Philip K." <philipk@posteo.net> writes:
>
>> [1:text/plain Hide]
>>
>> Gregory Heytings <gregory@heytings.org> writes:
>>
> ...
>>> That reminds me the famous "640 kb should be enough for anyone" ;-)
>>> Indeed, 26 letters is not enough.  Magit has three global commands, 
>>> Org-mode has three, and Bookmark+ has three keymaps.  With just three
>>> packages you've already used 35% of the available keys.  I hope you 
>>> understand that it can't be a long-term solution.  Moreover, AFAIU,
>>> packages cannot automatically bind their commands to C-c LETTER keys 
>>> anyway: these keys are strictly reserved for users in their personal
>>> configuration files.
>>
>> I think that's the pessimistic way to look at it, the optimistic one
>> would be to say that you only need 35% of the key-space. I don't have a
>> feeling for how many global keys people bind by default, one would have
>> to study public configurations to find out. But I still remain sceptical
>> that -- compared to memory usage -- that need for keys is rising that
>> much.
>
> Remember prefix keys here.  A user can define a prefix key anywhere in
> the region reserved for users.
>
> The manual says:
>
> "A small number of keys are reserved for user-defined bindings, and
> should not be used by modes, so key bindings using those keys are safer
> in this regard.  The reserved key sequences are those consisting of
> ‘C-c’ followed by a letter (either upper or lower case), and function
> keys <F5> through <F9> without modifiers (*note Modifier Keys::)."
>
> It does not ban using those keys as prefixes.  I can make <F9> a prefix,
> then I have the full keyboard to play with once again once I've pressed
> F9.

Sure, but if we are assuming that packages either automatically or
semi-automatically bind keys, they would have to mutually respect their
prefix keys. The guideline would have to be that e.g. C-α [letter] has
to be a map, and that package are only allowed to bind keys to these.

Also, I don't think package developers would want to comply if they had
to use a less ergonomic key such as <F5-9>, undermining the entire plan.

> BR,
> Robert Thorpe

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

> > the difference is that Emacs is a interactive computing environment
> > while GIMP and browsers are programs with extension models.
> 
> I'm not sure I understand the difference, and for
> most users Emacs is not an "interactive computing
> environment", it's a text editor, like Atom,
> Visual Studio, or Vim.

When speaking for, or about, "most users" of Emacs,
it would help to show some justification.

If you mean only that this is your personal
sense/impression/idea about what most Emacs users
think or how they act, then it's fine as is (but
it's better to explicitly say that).

More importantly:  Even if what you say were true,
that doesn't mean that that's what Emacs is _for_.

Emacs, like everything else, is really _for_
whatever you can do with it - whatever you can use
it for in a handy way.  And in the case of Emacs
that's a _lot_ more than what the typical text
editor offers.

We started with a Lisp-based text editor with freely
available source code, and we ended up with, well,
a super-powerful black hole. ;-)

Any description of Emacs includes features such as
extensibility, introspection, access to all source
code, etc.  It's really not a "regular" text editor,
and from that _it follows_ that its users are not
regular editor users (regardless of how many might
take advantage of the features that make it special,
and regardless of how deeply they take advantage of
those features).

> > It's ultimately up to the user what he or she
> > wants to do, and clever behind-your-back
> > customization seems more harmful and confusing
> > than the current state of affairs.
> 
> It's what most users expect.

See above.  Talk of "what most users expect" cries
out for (1) justification (how do you know?) and
(2) relevance (how important is what most expect
at the outset, if you're talking about new users?)

RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

> Regular users don't want to know what is going on,
> they don't care, and shouldn't have to care; for
> them an editor is just a tool for another task.

Apologies for chiming in here without having
read the context, and for responding to this
out of context.

I would say that such "regular users" aren't
what Emacs is about, and that regular (i.e.,
ordinary) Emacs users are, quite a bit,
interested in what is going on, to varying
degrees.  And with increasing degree as Emacs
becomes more a part of them.

Emacs, especially because of (1) Emacs Lisp
and (2) free software (source code, user
participation in development), blurs, and
can erase, the boundary between ordinary user
and hard-core Emacs developer.

Yes, for many Emacs users "an editor is just
a tool for another task" perhaps.  But for
many Emacs users - and "Emacs user" in its
real potential, that use-for-other-tasks is
not separate from knowing what's going on.

IOW, the "regular editor user" stereotype
doesn't really fit "Emacs user", even if
many Emacs users might start out looking
at Emacs as a regular editor and acting,
themselves, as regular users.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Leo Butler]

Gregory Heytings <gregory@heytings.org> writes:

>>> When you install a package whose purpose is to change the user
>>> interface, you expect it will change the user interface, don't you? 
>>> When you install an ad-blocker in your browser, you expect it will
>>> block ads, don't you?
>>
>> Again, the browser is a different situation.
>>
>
> For most users, it is not.  I guess you think the browser or GIMP are
> different situations, because you see them as mere tools, whereas you
> see Emacs as "more than a tool".  That's not the case for most Emacs
> users, for them Emacs is just a tool.  FWIW, when I open another
> editor, I see and use it as a mere tool for another task.

I agree with what Philip K. has written.

>
>>
>> This kind of aggressive behaviour just makes harder because you
>> don't know what is going on. This is how you confuse newcomers.

Agreed.

>>
>
> Regular users don't want to know what is going on, they don't care,
> and shouldn't have to care; for them an editor is just a tool for
> another task.

Sometimes, one really must understand what is going on.

I have found, through bitter experience, that expecting a piece of
software to 'just work' is a fool's paradise. My favourite example is a
bug I encountered in open/libreoffice where non-ascii digit characters
copied into a spreadsheet are simply treated as strings (and silently
coerced to 0 when doing arithmetic). I could go on a rant about how a
succession of developers have refused to fix the bug, how hard
libreoffice made it to even identify the bug, or how easy it would be to
fix it, but suffice it to say that 10 years later, the bug is still not
fixed and I use emacs.

Leo

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

[Re-attaching this to another thread.]

>
> Freeing 'C-z' up, for example, won't help most authors anyway.
>

Why not?  Could you perhaps elaborate?

>
> I have some doubts that we'll be able to free up nice enough key 
> bindings that third-party packages will all want to use.
>

What would be, for you, a nice enough key binding?

>
> And even if that happens, collisions between externally maintained 
> packages can happen just as well. There is no foolproof solution.
>

That's unavoidable, but still much better for newcomers than the current 
situation.  And there are ways to handle such collisions, which should be 
rare if the number of available keys is large enough, in a user-friendly 
way.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Dmitry Gutov]

On 15.02.2021 21:01, Gregory Heytings wrote:
> 
> [Re-attaching this to another thread.]
> 
>>
>> Freeing 'C-z' up, for example, won't help most authors anyway.
>>
> 
> Why not?  Could you perhaps elaborate?

In case it was not apparent from the preceding discussion: it's a 
contentious binding, and even if I was not using it myself, I should 
have been aware that a significant number of Emacs users already bind 
that key in their init scripts (to 'undo' or 'undo-tree-undo', I mean). 
Or use the default binding often, as some of the regulars here report.

As a package author, I would make an effort to choose a binding that is 
more likely to be unoccupied in all my users' configs. Or be, you know, 
free-able, which 'C-z' likely isn't.

>> I have some doubts that we'll be able to free up nice enough key 
>> bindings that third-party packages will all want to use.
>>
> 
> What would be, for you, a nice enough key binding?

Some examples:

- diff-hl adds some bindings under the 'C-x v' map because it is 
intended as an extension of VC.
- company doesn't add any global bindings, but has a number of them 
inside company-active-map (when completion is ongoing) and also 
recommends the user choosew a binding for `company-complete`. I use 
'C-/', personally.
- rspec-mode uses 'C-c ,' as the default keymap prefix but makes it 
customizable via a variable.
- robe uses a number of bindings reminiscent of SLIME. These days I 
should migrate some of them to the xref package, and the rest ('C-c C-d' 
most prominently) keep as-is. Could have migrated to Eldoc, but that one 
is moving in a weird direction lately.

>> And even if that happens, collisions between externally maintained 
>> packages can happen just as well. There is no foolproof solution.
>>
> 
> That's unavoidable, but still much better for newcomers than the current 
> situation.  And there are ways to handle such collisions, which should 
> be rare if the number of available keys is large enough, in a 
> user-friendly way.

FTR, I don't support the recent addition of bindings on 'C-x x', in part 
because those commands don't seem essential to me. But for the same 
reason I don't see a problem with any third-party mode continuing to use 
'C-x x' as its keymap prefix.

PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

[S Boucher apparently intended to reply to the following proposal sent on 
emacs-devel.]

=Proposal=

It is proposed to repurpose one key, and to reserve it in the key binding 
conventions for third-party packages.  The keys that could be reserved for 
that purpose are:

Option 1. C-z, with a single exception: "C-z C-z" would be bound to 
"suspend-frame"

Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound to 
"suspend-frame", and "M-z M-z" to "zap-to-char"

Option 3. C-o, with a single exception: "C-o C-o" would be bound to 
"open-line"

Option 4. C-o and M-o, with two exceptions: "C-o C-o" would be bound to 
"open-line", and "M-o M-o" to "facemenu-keymap"

=Rationale=

The current key binding conventions (see `(elisp) Key Binding 
Conventions') reserve keys for users, for major modes and for minor modes, 
but not for third-party packages [1].

When such packages need to bind a command to a key, they can (1) either 
suggest users to bind it to a key reserved for users (for example, 
org-mode suggests to globally bind "C-c c" to org-capture), or (2) bind it 
to a key currently unused by Emacs (for example, Magit binds "C-x g" to 
magit-status in buffers visiting a file in a Git repository).

Neither of these solutions are optimal: (1) requires an explicit 
configuration by the user, something which might confuse newcomers, and 
which other users might not want to do because they already use the keys 
reserved for users for other purposes, and (2) might conflict with the 
evolution of Emacs when one or more commands are bound to a yet unused 
key.

Reserving one key for third-party packages solves the above problems: 
third-party packages can automatically bind a few keys in that reserved 
area, without conflicting with keys reserved for users and without 
conflicting with future Emacs evolutions.

=Limit=

Conflicts are still possible, when two or more packages bind the same 
keys.  These are, however, conflicts between packages, not between a 
package and Emacs, or between a package and users' personal 
configurations.

Such conflicts are also less likely for typical users, who install a few 
packages each binding a few keys.

Finally, such conflicts can be dealt with without confusing users too 
much: a package could automatically choose fallback key bindings when the 
preferred ones are already used by another package, and/or issue a warning 
to the user that they need to bind its commands manually.

=Note=

[1] These conventions were written 25 years ago, at a time when there were 
far fewer third-party packages, and have not changed substantially since 
them.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Emanuel Berg via Users list for the GNU Emacs text editor]

Gregory Heytings wrote:

> It is proposed to repurpose one key, and to reserve it in
> the key binding conventions for third-party packages.

This rings a bell, isn't there such a key/keystroke already?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Francis Belliveau]

I vote against the removal of the current C-o functionality.  I would not want to use two keystrokes where I currently use only one.
I expect that those that use emacs in terminal windows will also find the remapping of C-z a problem, but that is actually never done in the middle of file modification so I wold expect it to be less of a problem.

Overall, I expect that if a package has a number of functions it wishes to map, if should have a method that installs itself into a keymap of user choosing.  Most packages do not need more than I few keys, although I have one that implements 15.  I put that behind M-o.

I do not know elisp enough to know if one can determine if a keystroke is a prefix key or not, but two functions could be implemented:
bind-keymap-to() and add-bindings-to-keymap() with appropriate prefixes and arguments of course.

A package that implements these two would allow a used to decide say:
    bind-keymap-to('C-o') and that would unbind C-o and convert it into a prefix key with empty keymap if it is not already a prefix key, then call the package's add-bindings-to-keymap('C-o').
Otherwise, if a user want to rebind a key that they already know is a prefix key, the can just call the "add-bindings" function.

Please do not tell me the syntax above is wrong since I expect that is it.  I only mean all that as a pseudo-code example.

The majority of the Rationale below is good, but it does not take into account the needs ot those who have decades of muscle-memory for high-speed editing that would get disrupted.  A command like "suspend" would never be used in an editing sequence, since it interrupts the edit session.  M-z and M-o are not keystrokes that I use, but I expect that those who do would have the same complaint with the remapping of "zap-to-char" thart I have with "open-line".  I cannot even guess why I would want a keystroke for "facemenu-keymap", but it sounds to me like it is already a prefix key.

BTW, your 25-years of history statement is inaccurate since I am sure that I have been using C-o since before 1990.


> On Feb 8, 2021, at 05:02, Gregory Heytings <gregory@heytings.org> wrote:
> 
> 
> [S Boucher apparently intended to reply to the following proposal sent on emacs-devel.]
> 
> =Proposal=
> 
> It is proposed to repurpose one key, and to reserve it in the key binding conventions for third-party packages.  The keys that could be reserved for that purpose are:
> 
> Option 1. C-z, with a single exception: "C-z C-z" would be bound to "suspend-frame"
> 
> Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound to "suspend-frame", and "M-z M-z" to "zap-to-char"
> 
> Option 3. C-o, with a single exception: "C-o C-o" would be bound to "open-line"
> 
> Option 4. C-o and M-o, with two exceptions: "C-o C-o" would be bound to "open-line", and "M-o M-o" to "facemenu-keymap"
> 
> =Rationale=
> 
> The current key binding conventions (see `(elisp) Key Binding Conventions') reserve keys for users, for major modes and for minor modes, but not for third-party packages [1].
> 
> When such packages need to bind a command to a key, they can (1) either suggest users to bind it to a key reserved for users (for example, org-mode suggests to globally bind "C-c c" to org-capture), or (2) bind it to a key currently unused by Emacs (for example, Magit binds "C-x g" to magit-status in buffers visiting a file in a Git repository).
> 
> Neither of these solutions are optimal: (1) requires an explicit configuration by the user, something which might confuse newcomers, and which other users might not want to do because they already use the keys reserved for users for other purposes, and (2) might conflict with the evolution of Emacs when one or more commands are bound to a yet unused key.
> 
> Reserving one key for third-party packages solves the above problems: third-party packages can automatically bind a few keys in that reserved area, without conflicting with keys reserved for users and without conflicting with future Emacs evolutions.
> 
> =Limit=
> 
> Conflicts are still possible, when two or more packages bind the same keys.  These are, however, conflicts between packages, not between a package and Emacs, or between a package and users' personal configurations.
> 
> Such conflicts are also less likely for typical users, who install a few packages each binding a few keys.
> 
> Finally, such conflicts can be dealt with without confusing users too much: a package could automatically choose fallback key bindings when the preferred ones are already used by another package, and/or issue a warning to the user that they need to bind its commands manually.
> 
> =Note=
> 
> [1] These conventions were written 25 years ago, at a time when there were far fewer third-party packages, and have not changed substantially since them.
> 

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Emanuel Berg via Users list for the GNU Emacs text editor]

Francis Belliveau wrote:

> I vote against the removal of the current C-o functionality.
> I would not want to use two keystrokes where I currently use
> only one. [...]

What about the Windows key, should we keep that or remove that
as well?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Francis Belliveau]

What Windows key?
C-o does "open-line" for me.  It has nothing to do with Windows" and I know of no such function.

> On Feb 8, 2021, at 19:05, Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> 
> Francis Belliveau wrote:
> 
>> I vote against the removal of the current C-o functionality.
>> I would not want to use two keystrokes where I currently use
>> only one. [...]
> 
> What about the Windows key, should we keep that or remove that
> as well?
> 
> -- 
> underground experts united
> http://user.it.uu.se/~embe8573
> https://dataswamp.org/~incal
> 
> 

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-08 19:38]:
> 
> [S Boucher apparently intended to reply to the following proposal sent on
> emacs-devel.]
> 
> =Proposal=
> 
> It is proposed to repurpose one key, and to reserve it in the key binding
> conventions for third-party packages.  The keys that could be reserved for
> that purpose are:
> 
> Option 1. C-z, with a single exception: "C-z C-z" would be bound to
> "suspend-frame"

Please consider that C-z is internationally vague and could cause some
inconveniences, as "z" is not always on the place where one think it
should be, it is often replaced with "y" on international
keyboards. It breaks some muscle memories.

I would not change C-z on terminal to nothing else but the long term
historical default.

> Option 3. C-o, with a single exception: "C-o C-o" would be bound to
> "open-line"

That would be so detrimental to remove C-o to do something else but
`open-line' function.

> The current key binding conventions (see `(elisp) Key Binding Conventions')
> reserve keys for users, for major modes and for minor modes, but not for
> third-party packages [1].

In my understanding those third party packages usually define major or
minor modes so the reservation of keys for third party packages is
thus already supported that way.

There are many commands and it may be better to tell third party
packages to advise user how to bind keys or to propose to users the
key bindings and how it would otherwise change existing key
bindings. That is not so hard really. It could be just one screen with
questions when user invokes the package first time.

For example, Org agenda keybindings was proposed to me, now I do not
know by which party, but I got used to their proposal. Even though I
do not use agenda, it is bound on {C-c a}. The proposal was in
accordance with the key binding convention. So it looks just fine and
clear.

So I think there is no need to reserve more keys for third party
packages. Finally, keys are limited.

> When such packages need to bind a command to a key, they can (1) either
> suggest users to bind it to a key reserved for users (for example, org-mode
> suggests to globally bind "C-c c" to org-capture), or (2) bind it to a key
> currently unused by Emacs (for example, Magit binds "C-x g" to magit-status
> in buffers visiting a file in a Git repository).

That is good way to go.

> Neither of these solutions are optimal: (1) requires an explicit
> configuration by the user, something which might confuse newcomers, and
> which other users might not want to do because they already use the keys
> reserved for users for other purposes, and (2) might conflict with the
> evolution of Emacs when one or more commands are bound to a yet
> unused key.

Yes, I would like myself that Emacs is optimal and very ready for
newcomers, but it is not.

"Emacs is the advanced, extensible, customizable, self-documenting
editor."

Emacs is advanced, thus not a simple editor. It is for beginners and
advanced users, as advanced users would never become advanced if they
were never beginners. But those beginners would never become advanced
if they are spared of configuring Emacs. Let us not forget that many
Emacs Lisp programmers became such due to fiddling with their
configurations in the first place. That is positive impact, not a
negative impact. We want people to learn programming. Programming is
confusing when one enters into the subject. And so is the subject of
computing and any other subject. That is the learning path.

That is why I think that (1) and (2) is not not optimal, it is state
of Emacs. Developers and contributors are making it newcomer friendly,
and that is never ending process and never completed, and never will
be. That is the state of Emacs.

These conversations also show that there will never be an optimal
state, there can be some consensus or approval by some users, but
never an optimal state.

> Reserving one key for third-party packages solves the above problems:
> third-party packages can automatically bind a few keys in that reserved
> area, without conflicting with keys reserved for users and without
> conflicting with future Emacs evolutions.

There are more than one keys reserved already in the manner you
described such as those reserved for users can be proposed and used by
third party packages, including those for minor and major modes, they
can be used by third party packages. Solution is just there.

Reserving key for third party packages sounds limiting to me. They may
have different preference than just one key.

Recently I have learned how to define the prefix command:

(define-prefix-command 'cf-map)
(global-set-key (kbd "s-p") 'cf-map) ;; By changing this one, one can
                                     ;; move all subsequent keys to
				     ;; different prefix
				     
(define-key cf-map "F" #'cf-find-files-of-person)
(define-key cf-map "L" #'cf-tabulated-last-people)
(define-key cf-map "l" #'cf-tabulated-people-of-account)
(define-key cf-map "a" #'cf-account-helm)
(define-key cf-map "d" #'cf-people-by-description)
(define-key cf-map "f" #'cf-follow-up)
(define-key cf-map "i" #'cf-people-by-interactions)
(define-key cf-map "m" #'cf-people-by-mark-new)
(define-key cf-map "n" #'cf-create-contact)

In my opinion that is great way of defining keys for third party
packages. They could define the full key bindings list and let the
user decide on the prefix key. They could propose some prefix key. It
is one line in the configuration. It is something like:

(global-set-key (kbd "s-p") 'cf-map)

Or

(global-set-key (kbd "C-c") 'cf-map)

or similar.

As not to confuse users programmer may invoke a wizard question:

"It is detected that you could use following prefix keys for third
party package:

s-p (Super/Hyper key may have Windows logo on Windows keyboards)

C-.

C-,

which one do you like to use as prefix key for this third party
package?

Some question as above could help users quickly decide on a prefix and
the line could be automatically inserted into the configuratio file.

Otherwise, simple explanation and advise to user how to place the
configuration line is also minimizing any confusions. 

> Finally, such conflicts can be dealt with without confusing users too much:
> a package could automatically choose fallback key bindings when the
> preferred ones are already used by another package, and/or issue a warning
> to the user that they need to bind its commands manually.

Good idea. So those packages could even now automatically do
that as there are many keys available.

In general I just think that more marketing is required to package
authors on how to prepare key bindings and let users decide on it.

Maybe one could make a package that changes the prefix key or various
packages or the package that could "see" which packages are used and
which of them need positioning of their prefix keys. Then such package
could ask user with proposal:

- C-c bind prefix key for Org functions

- C-, bind prefix for Magit functions

Approve or change above y/n?


Jean

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>> The current key binding conventions (see `(elisp) Key Binding 
>> Conventions') reserve keys for users, for major modes and for minor 
>> modes, but not for third-party packages [1].
>
> In my understanding those third party packages usually define major or 
> minor modes so the reservation of keys for third party packages is thus 
> already supported that way.
>

That's not correct, many packages (not all of them, but many) implement 
commands that are intended to be globally bound.  The "org-capture" 
command is an example.  A package implementing advance bookmark commands 
is another one, a packages implementing a dictionary search command is yet 
another one.

>
> There are more than one keys reserved already in the manner you 
> described such as those reserved for users can be proposed and used by 
> third party packages, including those for minor and major modes, they 
> can be used by third party packages.
>

Third-party packages cannot do that, and they do not do that.  A 
third-party package cannot bind a key C-c LETTER key, it can at best 
advise its users to do so.  It's what Org-mode does.

>
> Maybe one could make a package that changes the prefix key or various 
> packages or the package that could "see" which packages are used and 
> which of them need positioning of their prefix keys. Then such package 
> could ask user with proposal:
>
> - C-c bind prefix key for Org functions
>
> - C-, bind prefix for Magit functions
>
> Approve or change above y/n?
>

The first question is not an allowed one, C-c can only be used by users.

The second question is not a good one, C-, cannot be used in terminals.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-09 12:18]:
> 
> > > The current key binding conventions (see `(elisp) Key Binding
> > > Conventions') reserve keys for users, for major modes and for minor
> > > modes, but not for third-party packages [1].
> > 
> > In my understanding those third party packages usually define major or
> > minor modes so the reservation of keys for third party packages is thus
> > already supported that way.
> > 
> 
> That's not correct, many packages (not all of them, but many) implement
> commands that are intended to be globally bound.  The "org-capture" command
> is an example.  A package implementing advance bookmark commands is another
> one, a packages implementing a dictionary search command is yet
> another one.

Alright, but without reading the text below, I do not see here what is
not correct and how is your paragraph in any contradiction to my
quoted statement above. Maybe you know this technically better.

If I remember well org-capture suggested {C-c c} and I remember it was
suggested to me to place this line in the init.el:

(global-set-key "\C-cc" 'org-capture)

so I did so. This is all in alignment with what I meant, maybe I have
not expressed me well, and is in alignment on what you said.

Package authors may then research which key could be best and give
suggestions, but they will normally not bind it for user.

Then they give suggestions in accordance with the reserved key bindings.

> > There are more than one keys reserved already in the manner you
> > described such as those reserved for users can be proposed and used by
> > third party packages, including those for minor and major modes, they
> > can be used by third party packages.
> 
> Third-party packages cannot do that, and they do not do that.  A third-party
> package cannot bind a key C-c LETTER key, it can at best advise its users to
> do so.  It's what Org-mode does.

That is what I also meant. I do not see disagreements, but you see. It
is interesting.

> > Maybe one could make a package that changes the prefix key or various
> > packages or the package that could "see" which packages are used and
> > which of them need positioning of their prefix keys. Then such package
> > could ask user with proposal:
> > 
> > - C-c bind prefix key for Org functions
> > 
> > - C-, bind prefix for Magit functions
> > 
> > Approve or change above y/n?
> > 
> 
> The first question is not an allowed one, C-c can only be used by
> users.

OK but I do not see disagreement:

- when text message in the package proposes to user to bind C-c c for
  org-capture that is proposal and user can decide if to accept it or
  not

- package could ask user to insert such configuration. Computer
  software should be smarter than it is today. Users still need to do
  a lot of work. Little more artificial intelligence is needed.

- dedicated imaginary package could manage and help users with
  placement of keys and collisions between packages. I would regard
  that as artificial intelligence.

> The second question is not a good one, C-, cannot be used in terminals.

That was an example. It was not meant to be 2 choices, it was not
meant to be those keys specifically, artificial intelligence program
would find out possible choices and have maybe some "mind" of most
popular packages and could help user with choices and let user make
decisions. Such program would recognize which key bindings could be
possibly bound and ask user to bind it conveniently but which exact
key bindings would be offered would be left to the algorithm.

Jean

RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

> > The current key binding conventions (see `(elisp) Key Binding
> > Conventions') reserve keys for users, for major modes and for
> > minor modes, but not for third-party packages.
> 
> In my understanding those third party packages usually define major or
> minor modes so the reservation of keys for third party packages is
> thus already supported that way.

The question is about reserving keys for 3rd-party
code so that _Emacs itself_ doesn't bind them by
default.  It's one thing for a 3rd-party library
to possibly conflict with another such.  It's a
different thing if Emacs suddenly binds keys by
default that the library has bound.

And no, there's no limitation that 3rd-party code
bind keys only in major- or minor-mode keymaps.

In general, it's more polite for 3rd-party code
not to bind global keys by default.  But it can,
and it sometimes does.  Use of a 3rd-party is
optional, just as turning on a major or minor
mode is optional.

> So I think there is no need to reserve more keys for third party
> packages. Finally, keys are limited.

The question is not about reserving keys
for 3rd-party use _from users_.  It's about
reserving them from Emacs itself, i.e., so
they don't become new _default_ bindings.

(And it can't be about reserving "more" keys
for 3rd-party code, as _NO_ keys are reserved
for them so far.)

There is no question about not allowing
_users_ to bind some keys.  Users can bind
or unbind ANY keys.  Always.

> many Emacs Lisp programmers became such due to fiddling with their
> configurations in the first place. That is positive impact, not a
> negative impact.

100%, yes.  (And maybe all, not just many.)

> > Reserving one key for third-party packages solves the above problems:

(No, it doesn't.)

> > third-party packages can automatically bind a few keys in that
> > reserved area, without conflicting with keys reserved for users and without
> > conflicting with future Emacs evolutions.
> 
> There are more than one keys reserved already in the manner you
> described such as those reserved for users can be proposed and used by
> third party packages, including those for minor and major modes, they
> can be used by third party packages. Solution is just there.

There are currently NO keys reserved for 3rd-party
code, so that Emacs itself won't bind them by default.

There is no question of reserving any keys from
users, so they can't use them.  Never has been,
never will be.

FWIW, I disagree with Gregory's proposal, which
is a scaled-down version of my proposal, which
is to reserve _ALL_ keys currently not bound by
default, for 3rd-parties to use.  He proposes to
reserve only one key for that.

IOW, I proposed that Emacs keep its mitts off
the few remaining top-level keys (which includes
top-level prefix keys).  We should at least have
a _moratorium_ on such grabbing by Emacs.

Gregory's reduction of my proposal is to reserve
only _one_ top-level key for 3rd-party use.
Emacs itself would be free to bind all the
remaining keys by default.  I oppose that, even
if someone will say that one is better than none.

> Reserving key for third party packages sounds limiting to me.
> They may have different preference than just one key.

Yes.  There are good reasons for any party: Emacs
itself, a 3rd-party, or a user, to want to use
any particular top-level key, including using it
as a prefix key.

> Recently I have learned how to define the prefix command...
> In my opinion that is great way of defining keys for third party
> packages. They could define the full key bindings list and let the
> user decide on the prefix key. They could propose some prefix key.
> It is one line in the configuration. It is something like:
> 
> (global-set-key (kbd "s-p") 'cf-map)

Exactly.  The binding can be optional (e.g. by
command or user option).  Or it can be provided
by default.

A user can easily move the whole set of keys on
that prefix key to another prefix key - or move
some, or none.

Grouping keys on a keymap is a great way to make
them available as a set.  And sometimes it makes
sense for a library to provide more than one set.

> which one do you like to use as prefix key for this third party
> package?
> Some question as above could help users quickly decide on a prefix and
> the line could be automatically inserted into the configuratio file.

Bookmark+ just has two user options, whose values
are lists of prefix keys.  (The value will usually
be a singleton list - just one prefix key, but if
you want more...)

`bmkp-bookmark-map-prefix-keys' - default: `C-x x'
`bmkp-jump-map-prefix-keys'     - default: `C-x j'

[But Emacs has just decided to usurp `C-x x' for
a default binding.  Previously, the Bookmark+
default was `C-x p', but then Emacs usurped that
for its Project library, so I changed to `C-x x'.
You get the picture - why 3rd-party code could
use a break from Emacs claiming more territory
for default bindings.]

You can set either option to nil to not have any
such prefix key.  And you can easily change to
different prefix keys.  You need not know anything
about how to create or bind prefix keys.

RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>
> FWIW, I disagree with Gregory's proposal, which is a scaled-down version 
> of my proposal, which is to reserve _ALL_ keys currently not bound by 
> default, for 3rd-parties to use.  He proposes to reserve only one key 
> for that.
>

That's not the proposal, that's the way you look at the proposal.  The 
proposal is to free one or two keys, and to reserve them for third-party 
libraries.  Freeing one or two keys is (would be) an effort from the 
viewpoint of Emacs, which would give more freedom to both Emacs (to use 
the other keys as it wishes) and to third-party libraries (to use these 
keys as they wish).

Your proposal, "to reserve _ALL_ keys currently not bound by default", has 
I fear no chance whatsoever to be adopted.  Emacs evolves, and deciding 
that it cannot bind any new key from now on would be an arbitrary 
constraint that would impair its evolution.

RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

> > FWIW, I disagree with Gregory's proposal, which is a scaled-down
> > version of my proposal, which is to reserve _ALL_ keys currently
> > not bound by default, for 3rd-parties to use.  He proposes to
> > reserve only one key for that.
> 
> That's not the proposal, that's the way you look at
> the proposal.  The proposal is to free one or two keys,

You clearly said _one_ key, many times.  Glad to
hear now that it's two keys (or at least "1 or 2").

> and to reserve them for third-party libraries.  Freeing one or two
> keys is (would be) an effort from the viewpoint of Emacs,

Not if they're currently not bound by default.
Those are the keys I spoke of: keys not already
bound by default.

> which would give more freedom to both Emacs (to use the other
> keys as it wishes)

Emacs already has that freedom.  And it's using
it more and more, narrowing the set of keys not
bound by default.  It's getting pretty tight.
In the last year I've had to move a prefix key
I use _twice_ now.

> and to third-party libraries (to use these
> keys as they wish).

> Your proposal, "to reserve _ALL_ keys currently not
> bound by default", has I fear no chance whatsoever
> to be adopted.

It certainly has no chance if it's not even
proposed.  And your immediate subsequent
pull-back proposal hasn't helped.

> Emacs evolves, and deciding that it cannot bind any
> new key from now on would be an arbitrary
> constraint that would impair its evolution.

1. I proposed a _moratorium_.
2. I explicitly said that maintainers could override
   it, and that it would be good to solicit discussion
   before doing so.

Instead of designating some single prefix key as
reserved for 3rd-party use, why not just have
Emacs lay off binding keys by default for a while?

There are a bunch of keys still available, though
there's been more encroachment recently.  My ask
is just to put up a sign, "Wilderness area, no
further development now, please".  Your proposal
is to designate a tiny patch as the only area to
protect from development.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>> That's not the proposal, that's the way you look at the proposal.  The 
>> proposal is to free one or two keys,
>
> You clearly said _one_ key, many times.  Glad to hear now that it's two 
> keys (or at least "1 or 2").
>
>> and to reserve them for third-party libraries.  Freeing one or two keys 
>> is (would be) an effort from the viewpoint of Emacs,
>
> Not if they're currently not bound by default.
>

I wonder: did you actually read the proposal?

>> Your proposal, "to reserve _ALL_ keys currently not bound by default", 
>> has I fear no chance whatsoever to be adopted.
>
> It certainly has no chance if it's not even proposed.  And your 
> immediate subsequent pull-back proposal hasn't helped.
>

I'm sorry to read you've seen it as a pull back.  What I saw was that your 
request was being ignored, and I tried to help with something more 
constructive.

RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

> >> That's not the proposal, that's the way you look at the proposal.
> >> The proposal is to free one or two keys,
> >
> > You clearly said _one_ key, many times.  Glad to hear now that it's
> > two keys (or at least "1 or 2").
> >
> >> and to reserve them for third-party libraries.  Freeing one or two
> >> keys is (would be) an effort from the viewpoint of Emacs,
> >
> > Not if they're currently not bound by default.
> 
> I wonder: did you actually read the proposal?

Yes.  There's no effort needed if all keys not
currently bound are explicitly freed from use
for default Emacs key bindings.  A fortiori,
for just one or two of them.

Of _them_ - the unbound keys.

Of course if keys that are currently bound by
default are to be freed up then some adjustment
would need to be made.  But no effort is needed
for keys not yet bound - zero, beyond documenting
the fact.

By proposing to free up keys already bound, you
create more effort than is needed (zero), and you
solicit just the kind of back-&-forth objections
that have ensued: this key vs that key: Which
ones should be freed for 3rd-party code?  And
what if we switched this and that?  Or we did
this instead?  Or...?

The simple answer, as a starting point, is _none_
of those keys.  Just free up keys that are not
yet taken, just say that Emacs won't take them.

Additional discussion about possibly freeing up
more keys, which are currently taken, is also
welcome, but it should be separate from staking
out, now, the currently unbound keys as reserved
for 3rd parties.

Additional discussion about possibly refactoring
Emacs key bindings is also welcome.  And there
too I've participated.  There are repeatable keys
whose bindings are currently wasted.  There are
keys whose commands are not so useful or not so
commonly used.  There are keys that would be
better off used as prefix keys.  All of that is
ripe terrain for making keys more useful and
more available.

But all of that entails arguing about _changing_
existing keys, which as you well know is iffy,
risky territory.

My proposal is to separate any and all such
possible default key-binding _changes_ from the
simple act of declaring the keys so far unbound
by default to be reserved for 3rd-party code.

No default keys to relearn or fight over.  Just
a declaration of a moratorium on using up the
remaining virgin keyspace territory.

> >> Your proposal, "to reserve _ALL_ keys currently
> >> not bound by default", has I fear no chance
> >> whatsoever to be adopted.
> >
> > It certainly has no chance if it's not even
> > proposed.  And your immediate subsequent
> > pull-back proposal hasn't helped.
> 
> I'm sorry to read you've seen it as a pull back.
> What I saw was that your request was being ignored,
> and I tried to help with something more constructive.

I would welcome any such support, if that really
is your intention.

It took decades just to get `transient-mark-mode'
turned on by default.  Same thing for `font-lock-mode'.

I have no illusions about how difficult change is.
But there's no failing like not being willing to
propose something just because it looks hard to
get passed.  There's no failing like giving up
without trying.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>
> But no effort is needed for keys not yet bound - zero, beyond 
> documenting the fact.
>

The effort, or the absence of effort, is not the important point here. 
The main point is freedom: give more freedom to both Emacs and third-party 
libraries.  And "documenting the fact that keys not yet bound cannot be 
bound anymore" hinders Emacs' freedom.  I know, you also said that 
"exceptions would be possible with the approval of maintainers", but 
that's precisely what happened with the new "C-x x" key, and you objected 
anyway.

>
> My proposal is to separate any and all such possible default key-binding 
> _changes_ from the simple act of declaring the keys so far unbound by 
> default to be reserved for 3rd-party code.
>

That just can't happen, it would be a arbitrary constraint that would 
impair Emacs' evolution, it would mean that hundreds of small or large 
potential improvements would not be possible anymore.

>> I'm sorry to read you've seen it as a pull back. What I saw was that 
>> your request was being ignored, and I tried to help with something more 
>> constructive.
>
> I would welcome any such support, if that really is your intention.
>

FWIW, it was indeed really my intention.  The proposal is an attempt to 
find a reasonable middle ground that would give as much freedom as 
possible to Emacs, as much freedom as possible to third-party library 
developers, and without changing users' habits too much.

RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Drew Adams]

> > But no effort is needed for keys not yet bound
> > - zero, beyond documenting the fact.
>
> The effort, or the absence of effort, is not the
> important point here.

You're the one who brought up the "effort" needed
by Emacs to carry out this or that proposed change.
You claimed that your proposal needed less effort.
I argued that it needs more effort (> zero).

This was important enough that you brought it up.
Now it's not important.  OK.

> The main point is freedom: give more freedom to both Emacs and third-
> party libraries.  And "documenting the fact that keys not yet bound
> cannot be bound anymore" hinders Emacs' freedom.  I know, you also said that
> "exceptions would be possible with the approval of maintainers", but
> that's precisely what happened with the new "C-x x" key, and you
> objected anyway.

Maintainers decide.  I accept that - that's their
role, always, including on those occasions where
I might disagree.

The entire discussion was brought to emacs-devel
- not by me - from a bug thread, where `C-x x'
was taken over willy nilly, yes, over my objection.

And the bug/enhancement request was much narrower.
The decision was to bind a _global_ key by default.
Gigantic overkill, for the narrow problem raised
by the bug report.

I agreed (in emacs-devel, when discussed there,
and in the bug thread before that) that such wide
decisions - wider than the bug thread - should
preferably follow wider discussion in emacs-devel.

Half of the discussion in emacs-devel was/is about
this problem that some big, wide-ranging change
gets made in a bug thread, without many eyes seeing
it or minds discussing it.  That's a problem (IMO
- the maintainers disagree).

Wrt the actual change made:

I objected that, within the last year, first prefix
key `C-x p' was taken over, so I changed my code
to use `C-x x' instead, and now `C-x x' was also
taken over.  That's quite a bit to lose in a year.
And both changes were made in bug threads - no
discussion in emacs-devel.

I objected to that, and I still object.  It's not
I who decide, and that's fine.  But my opinion
that this isn't a good change, and that such things
should be discussed in emacs-devel, remains.

I'm not so worried as you about Emacs's "freedom"
to bind the keys it wants.  Casting this as a
question of "freedom" is alarmist and ridiculous,
IMO.  This is a question about what key-binding
conventions we should have, nothing more.

> > My proposal is to separate any and all such
> > possible default key-binding _changes_ from
> > the simple act of declaring the keys so far
> > unbound by default to be reserved for
> > 3rd-party code.
> 
> That just can't happen, it would be a arbitrary constraint that would
> impair Emacs' evolution, it would mean that hundreds of small or large
> potential improvements would not be possible anymore.

Not at all.  It would mean that Emacs would try
harder not to add new default key bindings.  It's
not trying hard enough now - that's the problem.
IMO, it's gotten worse lately, when we can least
afford it (available keys are scarcer and scarcer).

I asked for other solutions to the problem (still
asking).  And the maintainer's reply was that
there is no problem.

Yes, you proposed another answer to the problem,
and that's fine.  It's not as good an answer as
mine, IMO, but at least you offered something.

> > I would welcome any such support, if that
> > really is your intention.
> 
> FWIW, it was indeed really my intention.  The proposal is an attempt to
> find a reasonable middle ground that would give as much freedom as
> possible to Emacs, as much freedom as possible to third-party library
> developers, and without changing users' habits too much.

That's a good intention, though the ideas that
this is about "freedom", and that Emacs needs
more "freedom" to add default key bindings,
are misguided, IMO.

And as I said, by proposing to use a currently
bound key for this you increase, not decrease,
the contention and argument over which keys
Emacs should "lose" to this, and you increase,
not decrease, the need for users to change habits.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>>> My proposal is to separate any and all such possible default 
>>> key-binding _changes_ from the simple act of declaring the keys so far 
>>> unbound by default to be reserved for 3rd-party code.
>>
>> That just can't happen, it would be a arbitrary constraint that would 
>> impair Emacs' evolution, it would mean that hundreds of small or large 
>> potential improvements would not be possible anymore.
>
> Not at all.  It would mean that Emacs would try harder not to add new 
> default key bindings.
>

I see your point, but two maintainers clearly replied to your proposal and 
said they will never agree with it.  IMO it would be better to take that 
as a postulate for further reflection.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Robert Thorpe]

Can someone tell me....  What exactly is this thread about?  Is it a
formal request for input from the Emacs maintainers?  I.e. is it like a
poll?

Or is it just a discussion about what they may do?

BR,
Robert Thorpe

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Emanuel Berg via Users list for the GNU Emacs text editor]

Robert Thorpe wrote:

> Can someone tell me.... What exactly is this thread about?
> Is it a formal request for input from the Emacs maintainers?
> I.e. is it like a poll?
>
> Or is it just a discussion about what they may do?

Ha :) I don't understand anything either.

And what do you mean "this thread", there are FOUR threads
about this, and probably additionally at enacs.devel and
emacs.bugs as well :)

  Re: PROPOSAL: Repurpose one key and reserve it for
  third-party packages

  Re: not good proposal: "C-z <letter>" reserved for users

  Re: Proposal: "C-z <letter>" reserved for users

  Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

??? :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>
> I don't understand anything either.
>
> And what do you mean "this thread", there are FOUR threads about 
> this [...]
>
> Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
>
> Re: not good proposal: "C-z <letter>" reserved for users
>
> Re: Proposal: "C-z <letter>" reserved for users
>
> Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for 
> third-party packages
>

What happened is that the "PROPOSAL: Repurpose one key..." thread was 
started on emacs-devel, and a few hours later S Boucher started a parallel 
thread with a similar subject but a different content on help-gnu-emacs. 
This did not contribute to clarity indeed.

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Marcin Borkowski]

On 2021-02-08, at 11:02, Gregory Heytings <gregory@heytings.org> wrote:

> Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound
> to "suspend-frame", and "M-z M-z" to "zap-to-char"

This I find surprising.  M-z is *extremely* useful, why would anyone
want to delegate it to two-key sequence like M-z M-z?

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Gregory Heytings]

>> Option 2. C-z and M-z, with two exceptions: "C-z C-z" would be bound to 
>> "suspend-frame", and "M-z M-z" to "zap-to-char"
>
> This I find surprising.  M-z is *extremely* useful, why would anyone 
> want to delegate it to two-key sequence like M-z M-z?
>

It's a proposal, meant to be discussed.  Many said that they never use 
M-z.  That's of course not enough to move it somewhere else, but it means 
that it could make sense.  And if it's not a frequently used command, 
pressing three keys instead of two is not that difficult.