GNU bug report logs - #19468
25.0.50; UI inconveniences with M-.

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 19468 <at> debbugs.gnu.org
Subject: bug#19468: 25.0.50; UI inconveniences with M-.
Date: Sat, 02 May 2015 15:45:17 +0300

> Cc: 19468 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.