bug#62194: 30.0.50; Two Eglot-over-Tramp tests are failing on master, passing on emacs-29

[Michael Albinus]

João Távora <joaotavora@gmail.com> writes:

Hi João,

>> I've applied the patch, but Thomas' recipe still blocks for me. Sorry to
>> tell you.
>
> Drats.  Reproduced.
>
> I honestly don't know what's going on.  Yesterday I got 0% failures,
> today I get 100% failures with the very same code.  Maybe there is some
> SSH/ControlMaster thing at the OS level that's tainting the experiment.

So I propose we let the state as-it-is in master. The relevant tests
pass successfully, and we have your workaround in eglot.el, which makes
the situation a little bit better. Just one remark: perhaps you could
change this to

--8<---------------cut here---------------start------------->8---
                        (let ((default-directory default-directory)
                              ;; bug#61350: Tramp turns on a feature
                              ;; by default that can't (yet) handle
                              ;; very much data so we turn it off
                              ;; unconditionally -- just for our
                              ;; process.
                              (tramp-use-ssh-controlmaster-options 'suppress)
                              (tramp-ssh-controlmaster-options
                               "-o ControlMaster=no -o ControlPath=none"))
--8<---------------cut here---------------end--------------->8---

For the Tramp < 2.6.0.3 it still works, because
tramp-use-ssh-controlmaster-options is non-nil, and
tramp-ssh-controlmaster-options is used. Starting with Tramp 2.6.0.3,
the value `suppress' forces Tramp to compute its own
tramp-ssh-controlmaster-options, which might be the same, or not. But it
is Tramp's responsibility to DTRT.

Note that I have plans to enable shared connections also for PuTTY, by a
similar option tramp-use-shared-connection (or similar, not decided
yet). But this will be relevant for MS Windows users only; I don't know
how many of them use eglot. And it will definitively be in Tramp 2.7
only.

As proposed. we shall close *this* bug. The reported problem is fixed,
and for everything else we have bug#61350.

> FWIW, removing the JUST-THIS-ONE make Thomas' example always pass, but
> it has other implications like the re-entrancy thing, which I don't
> understand.
>
> I don't have any better ideas at the moment, other than just biting the
> bullet and reading Tramp's code very closely.  I'll try my hand at
> adapting a process-filter into it as I described in bug#61350, but I
> don't know if I'll manage of course, since I'm not closely acquainted
> with the API.

I will continue to bring threads into play with Tramp, again. Slow
progress only. But perhaps, it helps to improve the situation.

> Very sorry for the noise,
> João

Best regards, Michael.