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

[Dmitry Gutov]

On 03.07.2020 08:55, Eli Zaretskii wrote:

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

I assume, yes.

But even if they do, I'm not sure how this extra capability could harm them.

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

Using the current directory will result in worse results almost always, 
IME. Prompting the user every time is not a great experience either.

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

Neither of the built-in ones does. :-)

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

Perhaps. To get better results, the user will have to set up the project 
configuration better.