GNU bug report logs -
#50906
xref-find-references blocks Emacs: asynchronous operation?
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 3 years and 257 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.