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

Previous Next

Full log

Message #26 received at 50906 <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 50906 <at> debbugs.gnu.org
Subject: Re: bug#50906: xref-find-references blocks Emacs: asynchronous
 operation?
Date: Tue, 05 Oct 2021 20:09:43 +0200

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

Previous Next

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