bug#61350: Eglot over Tramp freezes with large project

[João Távora]

Michael Albinus <michael.albinus@gmx.de> writes:

> Yes, but Tramp doesn't get the whole output with one
> accept-process-output call. It must use a while loop, until everything
> it expects has been arrived. So the process-mark also moves again and
> again, and cannot be used by Tramp directly.

Sure, but you wrote: "Tramp must know where the output to be parsed
starts in the buffer".  And I suggested that you arrange for that
_starting point_ to be given by the Lisp function 'point', not
'process-mark'.

> Everything correct. But the problem was that not the whole expected
> output hasn't arrived the buffer. I thought it was "stolen" by another
> process.

OK, but earlier you said that the process _had_ arrived in Tramp's
buffer (though this arrival was triggered by jsonrpc.el) but that Tramp
couldn't be made aware of it.  You wrote yesterday:

>>> It wasn't lost. The process output was retrieved and placed into the
>>> Tramp buffer, w/o Tramp's interaction.

Can you confirm that you no longer believe this to be the case?

> But yesterday's debugging has shown, that ssh ControlMaster
> seems to be guilty; it cannot handle large amount of data reliably.

So maybe one should disable it by default.  How does one disable it? I
have trouble understanding from tramp-use-ssh-controlmaster-options and
tramp-ssh-controlmaster-options.

> Yes, that's the place. Tramp waits for a trailing shell prompt that it
> tells that everything has been sent from remote. But this shell prompt
> didn't arrive, and Tramp hangs in waiting for this.

So the problem is now that the shell prompt didn't arrive after all,
because of controlmaster, not because of jsonrpc.el.  Can you confirm
this?

João