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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 23223@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 9 Apr 2016 06:12:29 +0300
> 
> >> 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.

I agree.

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

Would it help to only use the mode's syntax table, and avoid switching
on the major mode as a whole?

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

That problem is relevant for IDutils as well (the scanner is
determined by the file's extension only), so we already have a certain
(hopefully, small) number of misses and false positives.  I think this
cannot be entirely avoided.  So maybe we shouldn't try so hard
avoiding false positives.  E.g., the "M-x gid" command, which comes
with IDutils and is a trivial wrapper around lid invocation, simply
shows the output in a Grep-like buffer, through which you can step
with next-error.  It is lightning-fast: what takes 13 sec with
xref-find-references, takes less than 2 sec with "M-x gid".

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

Perhaps use insert-file-contents-literally, as decoding could slow
down things considerably.  You are only looking for ASCII text.  Also
note that a mode can be specified in file-local variables at the
file's end, though.