[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41821: 28.0.50; read-directory-name in vc commands should provide de
From: |
Dmitry Gutov |
Subject: |
bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects |
Date: |
Thu, 25 Jun 2020 16:50:24 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
On 25.06.2020 16:20, Eli Zaretskii wrote:
I mean, I'm not going to protest against an
extra wrapper, but that doesn't sound like it would solve any practical
problems. "Cleaner" solutions often have those.
In general, code that doesn't _have_ to be preloaded, shouldn't be.
If nothing else, it keeps the memory footprint of a bare Emacs
smaller, and thus prevents us from slipping down the slippery slope of
memory bloat.
And having vc-hooks call project.el functions at runtime would somehow
force us to preload it? How?
Actually, I have a question: isn't project.el conceptually a
higher-level feature than VC? If so, how come VC wants to call
project.el?
VC doesn't serve project.el only. project.el doesn't solely use VC.
Yes, but that's not what I asked. I have the impression that
project.el builds on VC as one project back-end, so it sounds strange
to me that VC turns around and calls project.el for something.
Considering one doesn't exclusively serve the other, I wouldn't say
there is a strict hierarchy.
To be more accurate, we're actually talking about different parts of VC
and project.el (the UI and infrastructure parts), which have different
relations.
Apparently Juri wants to use certain data collected and saved by
project.el UI, for convenience.
After reading the original complaint that Juri says he wanted to
resolve, I still don't understand why we use project.el for that. No
one says that every relevant VC repository must have been visited as a
project as part of the current Emacs session. Why not have some
relevant history in VC itself?
I would be totally fine with that solution as well.
The alternative would be to introduce some separate history-keeping
feature for the cases when VC code needs to ask the user to point to a
VC repository.
Exactly. Why not?
The downside, of course, is having the user input the same thing
multiple times sometimes. And some extra code.
Overall, both seem minor (and the inconvenience is going to be infrequent).
And if the history is collected by VC, it could be made available to
project.el commands that call into VC, right?
But we want to store history on all projects, not just VC based ones.
Anyway, if you-two feel strongly about keeping the current solution,
i.e. having VC commands use project.el-collected history, I'd
appreciate if that function could be moved to vc.el from vc-hooks.el,
thanks in advance.
We can't just move it: it accesses information private to project.el.
The best we could do is a wrapper function.
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, (continued)
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Eli Zaretskii, 2020/06/24
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Dmitry Gutov, 2020/06/24
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Eli Zaretskii, 2020/06/24
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Eli Zaretskii, 2020/06/24
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Dmitry Gutov, 2020/06/24
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Eli Zaretskii, 2020/06/24
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Dmitry Gutov, 2020/06/24
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Juri Linkov, 2020/06/24
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Dmitry Gutov, 2020/06/25
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Eli Zaretskii, 2020/06/25
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects,
Dmitry Gutov <=
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Eli Zaretskii, 2020/06/25
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Dmitry Gutov, 2020/06/25
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Eli Zaretskii, 2020/06/25
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Dmitry Gutov, 2020/06/25
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Eli Zaretskii, 2020/06/25
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Dmitry Gutov, 2020/06/25
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Eli Zaretskii, 2020/06/25
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Dmitry Gutov, 2020/06/25
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Eli Zaretskii, 2020/06/25
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Juri Linkov, 2020/06/27