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: Wed, 24 Jun 2020 21:44:01 +0300

On 24.06.2020 21:29, Eli Zaretskii wrote:
>> Cc: 41821 <at> debbugs.gnu.org, juri <at> linkov.net
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Wed, 24 Jun 2020 21:13:07 +0300
>>
>> On 24.06.2020 18:42, Eli Zaretskii wrote:
>>> So is it possible to have vc-known-roots defined in vc.el instead of
>>> in vc-hooks.el?
>>
>> Okay, but that new function delegates to code in project.el anyway, what
>> would be the practical difference?
> 
> It would be somewhat cleaner, I think.

That's the whole reason? 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.

> Doesn't vc.el already have some calls to project.el?

Nope.

>> OTOH, if you just said we shouldn't use project.el in vc/*, I could
>> understand that.
> 
> That'd be unreasonably harsh, I think.

But that would be a limitation I could understand (don't use 
non-preloaded code from preloaded code, period).

> 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.

Apparently Juri wants to use certain data collected and saved by 
project.el UI, for convenience.

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.

Previous Next

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