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

[Eli Zaretskii <eliz@gnu.org>]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 6 Apr 2016 03:37:39 +0300
> 
> On 04/05/2016 06:16 PM, Eli Zaretskii wrote:
> 
> > The important part of the Lisp-level profile appears below.  It looks
> > like we are visiting each match of each file in the list of matches,
> > and that takes most of the time.  Can this be avoided somehow?  The
> > 'lid' command already includes all the matches in Grep format, so why
> > are we visiting each match, when the information should be already
> > available?
> 
> Huh, yes, that's the area of optimization I've forgotten about (mostly 
> because of using plain Grep myself anyway).

But using plain Grep has the same problem: Grep reports the hits, and
we then go ahead and visit each hit, right?

> If id-utils (and some other tools we delegate to) know symbol
> boundaries, maybe we don't need to double-check.

It should know.

> However, Grep output, which 'lid --result=grep' also uses, only outputs 
> the line number, but not the starting column.
> 
> Take this example:
> 
> I'm searching for 'buffer'. The last line of the output looks like this:
> 
> xmenu.c:832:      set_buffer_internal_1 (XBUFFER (buffer));
> 
> How do I find the appropriate 'buffer' match in this line?

You already have the code that looks for the match in each line.  What
I had in mind is looking in the output of Grep or lid, instead of
visiting the file and looking in that file's buffer.  Does this make
sense?

> Or can we ask 'lid' (and, ideally, Grep too) to include the column of a 
> match in the output?

No, I don't think such an option exists.  It could be a great
enhancement request, though ;-)

> Grep has colorized output, so I should be able to work with that. But 
> not 'lid', it seems.

Another enhancement to request, I guess.