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

["João Távora" <joaotavora@gmail.com>]

On Sat, Mar 18, 2023 at 9:38 AM Michael Albinus <michael.albinus@gmx.de> wrote:
>
> 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.

I propose we still revert the two of your latest patches.  The situation
stays exactly the same in practice for now (bug#31350 broken, this bug
fixed, workaround in place, no-one knows what is really happening), but
with the added advantage that the code is still the same as in emacs-29.


> 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.

Makes sense.  If it's just this change, you can push this yourself.
Thanks in advance.

> 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.

OK.

Just a heads up, I asked for bug#61350 and this one to be "merged"
earlier.  Don't know what debbugs did about that, but didn't see any
practical effect

> > 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.

I think you should consider bring stuff _out_ of Tramp instead of _in_.

Consider removing tramp-a-o-p entirely, and segregating/segmenting
messages in a process filter.  This segregation is entirely textual
(no fs primitives) and does run the risk of reentrancy.  Then -- for
sync APIs -- 'throw' the complete message into whoever is blockingly
waiting for the answer with (catch ... (while (accept-process-output p))).

I've given a working example in bug#61350.  If you need timeouts
I can show you how to add them.

João