GNU bug report logs - #23223
25.0.92; Can xref-find-references be sped up?

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23223 <at> debbugs.gnu.org
Subject: bug#23223: 25.0.92; Can xref-find-references be sped up?
Date: Sat, 9 Apr 2016 06:12:29 +0300

On 04/07/2016 06:03 PM, Eli Zaretskii wrote:

> Heh, I completely forgot how IDutils work.  The ID database doesn't
> store the locations where the identifiers were found, all it stores is
> the list of identifiers found in each file.  When lid is invoked, it
> queries the database about the files that reference the identifier;
> then it opens each file in the query results, and searches for the
> identifier on each line of that file.  When lid is invoked to produce
> a Grep-like output and with the -w option (which is what we do), it
> searches each line for the moral equivalent of
>
>   [^[:alnum:]_]IDENT[^[:alnum:]_]
>
> where IDENT is the identifier we asked about.

That explains everything, thanks.

>> I was hoping you could serve as a liaison in that, being the sole user of id-utils that I know of, so far.
>
> I could do that, but given the explanation above of what -w means, it
> will hardly help us, right?

It might if -w were to be improved, though. We can request for it to be 
smarter and do the post-filtering itself, using a language-aware 
scanner. Even if no other feature is added, the accuracy of results will 
improve for all users of id-utils, and Emacs will automatically end up 
having to do less work for this feature.

That's not pressing, though.

> Right.  So I think we need to assume that the program we invoke to
> bring the matches is not smart enough anyway, and Emacs will have to
> search in the matches for those we want to present, filtering out the
> false positives.  This assumption seems to fit well all the programs
> that can support the queries required by xref-find-references.

Probably.

> I'm not sure I understand what you have in mind for that, though.  Are
> you going to switch the major mode of the temporary buffer as
> determined by the file name of each match?

Yes. We can avoid switching if the major mode of the previous match was 
the same as the current one. Having too many major modes involved in one 
search is highly unlikely, so the switching overhead shouldn't be too 
much of a problem, actually.

> Maybe we should take a
> hint from the major mode of the buffer in which the command was
> invoked?

That could only work for the output of xref-find-references, but not 
project-find-regexp, which is also in need of speeding up.

Anyway, whether we "take a hint" or not, we're going to end up with 
imperfect results: if we don't visit the target buffers, we're going to 
have to ignore all the ways Emacs allows specifying the major mode, 
aside from auto-mode-alist ("mode: " specification, 
interpreter-mode-alist, magic-mode-alist, magic-fallback-mode-alist).

Hmm. Maybe we can still support most of those using 
(insert-file-contents "file-name" nil 0 200), at the cost of some extra 
overhead.

Previous Next

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