GNU bug report logs - #41821
28.0.50; read-directory-name in vc commands should provide defaults from projects

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41821 <at> debbugs.gnu.org, juri <at> linkov.net
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

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.