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

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

[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: 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

[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

[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

[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

[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

[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

[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

[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

[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

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

* 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

[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:

> 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

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

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

[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

[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

[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: 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: [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

[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: [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: 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

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

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