GNU bug report logs -
#61350
Eglot over Tramp freezes with large project
Previous Next
Full log
View this message in rfc822 format
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
This bug report was last modified 2 years and 50 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.