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

[Dmitry Gutov]

On 05.10.2021 08:18, Arthur Miller wrote:

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

Why not? It should be possible with cooperative multithreading (which we 
have), at least in theory. Under the hood it would be based on async 
processes, of course.

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

Doesn't seem like it really can be reused directly: it launches a queue 
of processes. What we would need is a "queue" of result batches coming 
from one process. And we'd need some abstraction for it, not just 
concrete implementation.

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

Why not? Sometimes the regexp I have typed is wrong (too short, for 
example), and I need to stop the search to correct it. Or even if the 
regexp was right, I might discover it brings too many matches to be useful.

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

It's... an option too. And having lives with the current UI, I would 
probably be fine with it.

But I suppose a lot of users might want to be able to interact with the 
first results (that have been already rendered) before the search 
completes. Otherwise we're not really taking full advantage of 
asynchronous searching.