[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23223: 25.0.92; Can xref-find-references be sped up?

From: Dmitry Gutov
Subject: bug#23223: 25.0.92; Can xref-find-references be sped up?
Date: Sat, 9 Apr 2016 06:12:29 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

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


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.


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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]