[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 K. |
Subject: |
Re: PROPOSAL: Repurpose one key and reserve it for third-party packages |
Date: |
Thu, 11 Feb 2021 23:48:42 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
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.
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 K., 2021/02/10
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/11
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Philip K., 2021/02/11
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Philip K., 2021/02/11
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/11
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Philip K., 2021/02/11
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/11
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Philip K., 2021/02/11
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/11
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages,
Philip K. <=
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/11
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Philip K., 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 K., 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