[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
From: |
Philip Kaludercic |
Subject: |
Re: PROPOSAL: Repurpose one key and reserve it for third-party packages |
Date: |
Sat, 13 Feb 2021 15:28:27 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
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.
signature.asc
Description: PGP signature
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, (continued)
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Philip Kaludercic, 2021/02/12
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/12
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Philip Kaludercic, 2021/02/12
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/12
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Philip Kaludercic, 2021/02/12
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/12
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Philip Kaludercic, 2021/02/12
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/13
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Philip Kaludercic, 2021/02/13
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/13
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages,
Philip Kaludercic <=
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Emanuel Berg, 2021/02/13
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Philip Kaludercic, 2021/02/13
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/13
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Jean Louis, 2021/02/13
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Emanuel Berg, 2021/02/13
- Nothing is the list - Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Jean Louis, 2021/02/13
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Philip Kaludercic, 2021/02/13
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Jean Louis, 2021/02/13
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/13
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Philip Kaludercic, 2021/02/13