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

[Dmitry Gutov]

On 22.06.2020 01:49, Juri Linkov wrote:
> > > > +;; Or use project-try-vc after all. But this should be faster in the
> > > > +;; event when there actually are non-VC based projects in the list.
> > > > +(defun vc--known-vc-roots ()
> > > > +  (require 'project)
> > > > +  (defvar project--list)
> > > > +  (project--ensure-read-project-list)
> > >
> > > Calling internal project.el functions from vc.el?  Really?
> >
> > The alternative would be to create a function like that in project.el.
> >
> > But I hesitate to make it public, sorry.
>
> Why not?

Because I'd rather not have external code depend on what exact kind of 
project backend is in use.

> We have to decide which of them should be dependent.  It would be fine
> either way: project.el to use vc.el public functions, or vice versa.

There are other private functions shared between project.el and xref.el. 
So I this is fine, kind of.

But you have noted an alternative option below:

> > > > Personally, though, when I want behavior like this, I would probably just
> > > > type 'C-x p v'.
> > > 'C-x p v' is not a replacement for 'C-x v L'.
> >
> > 'C-x p v L', then?
>
> 'C-x v L' needs to provide a list of recently used repositories.

If you like.

> Actually, this feature doesn't depend on project.el, so recently
> used repositories could be recorded independently without project.el.

This is the alternative option. It would create a yet another file in 
the user's dir, though.

> But it would be nice to share these directories between project.el and vc.el.

Perhaps there could be a public function in project.el called 
project-known-roots.