GNU bug report logs - #61350
Eglot over Tramp freezes with large project

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Thomas Koch <thomas <at> koch.ro>, eliz <at> gnu.org, 61350 <at> debbugs.gnu.org
Subject: bug#61350: Eglot over Tramp freezes with large project
Date: Tue, 28 Feb 2023 11:33:54 +0000

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

> João Távora <joaotavora <at> gmail.com> writes:
>
> Hi João,
>
>>> It is stable. Except in the case of large amount of data, which is
>>> exceptional for Tramp usage.
>> ...is it though? :-) Can a feature that hangs when presented with more
>> data than usual (however one defines that) be considered stable?
> Tramp supports ControlMaster since Emacs 24. Eglot is the first case
> I've heard of problems. I don't deny it

That could be because, as far as I understand, Eglot is the first
"major" package to use the transparent (make-process ... :file-handler
t) which, AFAIU, means that Eglot's process, which doesn't really
transmit _that_ much data, is piped transparently through Tramp's
process managing the remote file whose buffer M-x eglot is executed in.

>>> It is essential. I have been beaten by many Tramp users to support it.
>> I'd say something "essential" is something you can't live without.  But
>> that doesn't seem to be the case here.
> Ohh. You haven't seen how much Tramp has been blamed because it doesn't
> support it out of the box.

I understand, but it's the occasionally-exploding racecar all over
again.  I understand your reasoning: you're betting that it's acceptable
for the ocassionally-exploded user to learn opt-out for a slightly
slower car.

The thing is they will probably blame the steering wheel, Eglot,
because -- Tramp being "transparent" -- that's what they see.

Ideally, we would just fix this.  It would be nice to understand what
actually happen and what information is lost, presumably to
ControlMaster's gremlins.  I think bringing in Eli's knowledge of
process.c internals could be beneficial here.

> Currently it's not possible. I'll investigate a way to disable
> ControlMaster per process. By this, the main Tramp process and other
> processes on the remote host could still profit from the performance
> boost, and other processes (like Eglot) could opt-out.

One thing I don't understand, here and in other bugs, is the "process"
model of Tramp.

Here are some questions.  Apologies in advance if some of them are in
the "FM".

1. When I open a single remote file on a remote host, I am creating
   Tramp process, I presume.

2. If I kill this buffer and re-visit it, is the Tramp process re-used
   somehow or is a new one created?

3. If I open another nearby file on the same host, I am sharing that
   Tramp process?

4. What about in a different host?

5. Is there any way to get an overview of which Tramp processes are
   "responsible" for each set of remote files?

6. Now if I M-x eglot in a Tramp remote file that I had been working on
   Eglot-less for a while, is the Eglot process tunneled through the
   existing Tramp process, reusing it, or is a new one started?

7. If an existing process is reused, is there any way to force Tramp to
   open a new one, perhaps with slightly different configuration
   options?

João

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.