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

[Philip Kaludercic]

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.

signature.asc
Description: PGP signature