bug#61350: Eglot over Tramp freezes with large project

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> We could start by understanding exactly what is triggering this reentrancy.
>> AFAIU, we don't.  If have a recipe to trigger is consistently, now we should
>> work backwards from there.
>
> I think we understand some of the problems well enough to think
> about solutions.

Does that "some" include _this_ problem?  Let's take this one for
example.

   make -C test filenotify-tests SELECTOR=file-notify-test04-autorevert

Michael reports that this reports "Forbidden reentrant call of Tramp" on
EMBA.  I've confirmed it fails locally with a different error:

   (file-error "‘tramp_stat_file_attributes 
/tmp/file-notify-testNkTum7/file-notify-testhEtklA’ does not return a valid 
Lisp expression: ‘’")

Good enough, a failure is a failure is a failure.

We know this was introduced by the recent changes
54ef338ba3670415cf47fabc33a92d4904707c7e.  But we don't know a lot of
other stuff

* Why the difference between Local and EMBA?

* How is this test supposed to work?

* Can we split the test to be shorter, as currently it takes between 25
  second and 120 seconds to run?

* What exactly breaks here?  The test fails consistently enough, that we
  should be able to log/instrument/debug.

IMHO, we can be answering this in parallel with -- but ideally before --
a deeper review of Emacs's process machinery.

We could also ask other questions, of course, like: could Tramp use a
process filter?  IMO these are very powerful tools and bring a
substantial degree of freedom of implementation.  Currently Tramp relies
on accept-p-o and then searches the process buffer for regexps.  To me,
that just seems more difficult and error-prone than process filters.

But even my own questions I would defer until after we have understood
this particular failure of file-notify-test04-autorevert on master.

João