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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 41821@debbugs.gnu.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 2 Jul 2020 22:37:36 +0300
> 
> > But Emacs is more than just an IDE, it can be and is used for many
> > other jobs.  For example, I customary take a break from my development
> > work to read email, and when doing so I might issue some Grep command
> > that I need for some email message I'm writing.  I don't think it's
> > right for Emacs to assume that every Grep I do is necessarily related
> > to the last project I was working on (which could be days in the past,
> > btw).  This way, we would need a command to "get out of" (or "close")
> > the project, which I think would be both a nuisance and absurd.
> 
> But it's for a default value (one you can insert using M-n, or not). 
> Most users won't even notice this.

You assume that most users don't know about or use M-n?  I do it all
the time, and would like to think others do as well.

> >> The use case is 'M-x xref-find-refereces' and xref backends which don't
> >> override xref-backend-references. In which case this command searches
> >> the current project using general purpose tools (one of semantic symref
> >> tools, or Grep).
> >>
> >> But xref backend != current project. They're technically and
> >> theoretically independent.
> > 
> > So you are saying that it might bring me the wrong references once in
> > a while?  That's not good, is it?
> 
> If an xref backend doesn't define the xref-backend-references method, 
> the alternative is no references at all.

The alternative could be to start with the current directory, or ask
the user.

But do we have xref backends that don't define the
xref-backend-references method?  If so, which ones don't?

> Whether the current implementation will give wrong results, and how 
> often, is difficult for me to predict. It also depends on what we 
> consider a "wrong reference". etags and elisp backends don't always give 
> perfect results for "find definition" either.

"Imperfect" and "completely wrong" is not the same at all.  Searching
the wrong directory hierarchy will get you the latter.