[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: |
Gregory Heytings |
Subject: |
Re: PROPOSAL: Repurpose one key and reserve it for third-party packages |
Date: |
Wed, 10 Feb 2021 11:07:18 +0000 |
Configuring a package, that provides a command as it's interface,
should be done by binding it to a key reserved for users. Just like
how configuring a minor mode is done by adding it to a hook or a major
mode by adding it to auto-mode-alist.
What most users do is that they install third-party packages through
their distro package manager, or through Elpa or Melpa, and they just
expect / would like it to work. That's what would happen when you
install extension packages in most (if not all) other software
(editors, browsers, ...): you don't have to manually fiddle with
configuration files to make them work.
If I install ffmpeg via apt on a Debian system, I expect it to work, in
the sense that I can invoke the command from the terminal whenever I
want to use it. I don't think the analogy works for browsers, since
add-ons are usually filters or added to right-click menus.
The point is that those "filters" or "right-click menus" are activated,
you can use them right away, you don't have to manually edit, say, the
~/.config/chromium/init.js file beforehand. If you had to do that, you
would likely think it's a badly designed browser. All Emacs users are not
programmers like you and me.
What might be interesting would be something like the gnu-elpa
package[0], or something that goes in the other direction, where a
package can recommend a keybinding, hook, etc. and "automatically"
configure itself if the user agrees.
If there is no keymap reserved for package keybindings, packages simply
cannot do that. The point of the proposal is only to make that possible.
The problem I see is that key-bindings are usually user configuration,
and e.g. Magit *works* without them. I can do M-x magit-status, right
after installing it. No extra configuration necessary. But if I want to
have it easier, it's easy to add.
For you and me, yes. For Emacs users in general, no.
I think Ivy is a good example where this should *not* be the case,
because it changes the user-interface that can be confusing.
When you install a package whose purpose is to change the user interface,
you expect it will change the user interface, don't you? When you install
an ad-blocker in your browser, you expect it will block ads, don't you?
Packaging doesn't do configuration, and we shouldn't encourage this
misunderstanding.
Some users, like you and me, don't want Emacs packages to automatically
configure themselves, that's fine and will always be possible. Other
users, like me when I install a GIMP plugin, want that GIMP plugin to be
automatically configured. I would be very confused if I had to manually
edit the ~/.config/GIMP/X.YZ/gimprc and/or ~/.config/GIMP/X.YZ/pluginrc
before using a plugin.
- 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, Thibaut Verron, 2021/02/09
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/09
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Thibaut Verron, 2021/02/09
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/09
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Stefan Monnier, 2021/02/09
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/09
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Sean Whitton, 2021/02/09
- Message not available
- Message not available
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Philip K., 2021/02/09
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages,
Gregory Heytings <=