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.