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

[Eli Zaretskii]

> Cc: 41821@debbugs.gnu.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 24 Jun 2020 21:44:01 +0300
> 
> >> 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?

Well, the whole issue at hand is a rather minor one.

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

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

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

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

Juri answers:

> It wouldn't be rational to duplicate this feature.
> Rather I think the project-list should be updated
> even on using vc commands such as 'C-x v d', i.e.
> project and vc should be more tightly integrated.

I don't think I agree.  First, I don't see any duplication here:
people could (and do) use VC directly, not through project.el, in
which case project.el history wouldn't help.  Moreover, using a
command such as "C-x v d" doesn't mean I want project.el record that,
again because I might be using project.el commands for projects that
aren't based on VC.

And if the history is collected by VC, it could be made available to
project.el commands that call into VC, right?

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.