bug#19468: 25.0.50; UI inconveniences with M-.

[Eli Zaretskii]

> Cc: 19468@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 2 May 2015 15:01:59 +0300
> 
> > I don't understand this new prompt, it says:
> >
> >    In directory: /patch/to/emacs/trunk/src/
> >
> > What does it ask about?  (I just pressed RET, since the directory
> > sounds correct.)
> 
> "[Search for references] in directory".

Do you mean it will only return matches in files in that directory,
even if ID says the file is elsewhere?

> Should the first three words be spelled out as well?

I cannot answer that without understanding the meaning of the prompt.

> > [Time passes] Ah, I see the reason: Some code that uses ID Utils
> > expects the file names in the ID database to be absolute.  So if I
> > create the ID database like this:
> >
> >     mkid -o ID /path/to/emacs/src
> >
> > then the feature starts working.
> 
> It works fine for me either way (whether called on /path/..., or .), 
> using mkid 4.6, on GNU/Linux.

If you type "lid", do you see absolute file names in both cases, or do
you see relative ones when ID was created by "mkid ." (note the dot)?

> Could it be a misfeature of the Windows port?

If you tell me that "lid" returns relative file names, and
xref-find-references still work, I will see if this is something
specific to Windows.

> > I think it should support relative names as well, by expanding them
> > relative to the directory in which the ID database was found.  And in
> > any case, claiming it found no references instead of saying something
> > about finding no files whose names were returned by ID Utils is a less
> > than useful error message, IMO.
> 
> ID Utils is used through several levels of indirection. xref can't be 
> aware of it.

I didn't say xref should fix this.  Is there no information  xref gets
from symref apart of the (empty) list of references?