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

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 30.09.2021 01:49, Stefan Kangas wrote:
>> Severity: wishlist
>> `xref-find-references' blocks Emacs while searching for matches.
>> This can take a long time to complete in large repositories.
>> It would be nice if it could work asynchronously, like e.g. `M-x rgrep'.
>
> Wishlist indeed!
>
> Daniel's bug report shows a good case for this kind of feature: huge projects
> where the search, even using fast tools (e.g. ripgrep), takes multiple
> seconds. So if results of such searches could be displayed incrementally, it
> would improve the perceive speed and usability.
>
> What can be done here:
>
> - Design an "asynchronous" format for xref-show-xrefs-function to
>   consume. FETCHER of a different shape. Not sure how it's going to work in 
> the
>   end -- maybe a simple-ish iterator (call a function again for more results),
>   but ideally it would look synchronous somehow, and the concurrency would be
>   achieved through the use of threads. Not sure if that's realistic.

Built-in threads are not realistic, what you probably want is async processes. I
was myself thinking of something for finding all references for implementing
this asynchronosly for help, in style of , but I have not yet come to implement
that. However I have looked at native comp, 'comp-run-async-workers' and how it
processes it's qeue. I have no idea if it can be somehow adapted/reused, but
something like that at least as an idea.

> - The new kind of fetcher would need to provide a way to abort the search, 
> since
>  'C-g' would not be available anymore.
It depends on how you would use it. If you would scan for references in the
background than you would be working with something else and wouldn't need
C-g. But reading your writing, something tells me that you would like to use it
interactively, which means you would start a *synchronous* operation, which
would use async workers, a lá Java's or MFC's thread workers to get responsive
and visible updates in real-time, while workers are still searching. In that
case you would still have C-g avaialable. On C-g you could signal worker
processes to quit.

Perhaps ...? :)