|
From: | Dmitry Gutov |
Subject: | bug#41890: 28.0.50; [PATCH]: Add bindings for project.el |
Date: | Thu, 18 Jun 2020 18:47:37 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
On 18.06.2020 16:38, Eli Zaretskii wrote:
Cc: 41890@debbugs.gnu.org, theo@thornhill.no From: Dmitry Gutov <dgutov@yandex.ru> Date: Thu, 18 Jun 2020 01:23:25 +0300I don't see how this is related to the issue at hand. All I'm saying is that a package, including its key bindings, shouldn't be loaded until some of its feature is invoked.But if we autoload the bindings definition forms, wouldn't that have essentially the same effect?How is this different from bookmark.el?
I don't really know much about bookmark.el, or the way it was written and why.
And if we don't want these key bindings to be available always, we could have a separate autoloads file for project.el. Some packages do that already.
We might not want them when the package is simply installed through ELPA. But we'll probably always want them on by default in Emacs 28 and newer. I'm curious what Stefan thinks about it.
We could make the keybindings autoloaded without having them defined them when the package loads, couldn't we? By having the define-key on the same line as the autoload cookie, like bookmark.el does.That would generally be considered problematic because the keymap would take effect right after the user updates to the newest version of project.el. Because package.el also compiles and evaluates autoloads.Why is that a problem? A user who updates project.el is most probably going to use it, right?
Probably. But it's also a dependency of certain packages like eglot or xref, so it's not a given that the user chose to update it intentionally.
And if we do care about this, we could use a separate autoloads file.
Which the users would have to (require '...)?
[Prev in Thread] | Current Thread | [Next in Thread] |