Re: call-process should not block process filters from running

[sbaugh]

Michael Albinus <michael.albinus@gmx.de> writes:
> sbaugh@catern.com writes:
>
> Hi Spencer,
>
>>> project-find-regexp also works over Tramp, though. Given Michael's
>>> objections in the other subthread, do you expect the proposed change
>>> might break that? If it simply keeps the current limitations (when
>>> invoked on a remote host), that's probably fine.
>>
>> There are a number of possible alternative approaches.  One is to change
>> project-find-regexp to use start-file-process instead of process-file.
>> This would make project-find-regexp only work with TRAMP backends that
>> support start-file-process, which is a loss, but there aren't actually
>> many such backends AFAIK.
>>
>> It would be nice if Michael would respond to the actual question I
>> posed, which is "how to avoid this loss".
>
> I must have missed this in the thread, sorry. Could you pls repeat the
> question?
>
> Best regards, Michael.

Here we are talking about switching project-find-regexp to internally
use start-file-process instead of process-file, since
project-find-regexp can take non-trivial amounts of time, but retain the
current synchronous UI.  The benefit would be to not block other Lisp
from running while project-find-regexp runs, including in filters and
timers.  But actually running the process underlying project-find-regexp
asynchronously (e.g., having process filters and sentinels on it) is not
necessary.

However, switching from start-file-process to process-file loses support
for some TRAMP backends.  The question: Is there a way to get the
benefit (not block other Lisp from running) without the cost (losing
support for some TRAMP backends)?

Although maybe the answer is to just ensure that every TRAMP backend
supports start-file-process, since for example project-compile won't
work with out that also.