bug#50906: xref-find-references blocks Emacs: asynchronous operation?

[Helmut Eller <eller.helmut@gmail.com>]

On Tue, Oct 05 2021, Dmitry Gutov wrote:

> A really fast searcher solves the biggest part of the problem, but
> we'd still be left with very imprecise searches (many matches) locking
> up Emacs for seconds, since the Lisp overhead processing a match is
> unavoidably larger than the time it takes for a search program to
> print it. Using lazy sequences could allow us some leeway as well --
> namely, processing only the first N hits initially, and then
> processing the rest only if the user requests that.
>
> If we only target this kind of improvement, the "abort" functionality
> could wait.

Yes, limiting the time that Emacs is locked up, by limiting the number of
hits that Emacs accepts in one chunk, seems like the way to go.

> We'd still need to choose between sorting the results and
> saving on parsing the output buffer eagerly, though.

Theoretically it should be possible to sort the first chunk and display
it.  Then, when the next chunk arrives, merge it in, à la heap-sort, and
update the display accordingly.  Probably not worth the effort, though.

Also, I think that the only "sorting" that we actually do, is grouping
by filename.  And that doesn't seem all that important to me.

Helmut