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

[Philip K.]

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.

signature.asc
Description: PGP signature