GNU bug report logs -
#61350
Eglot over Tramp freezes with large project
Previous Next
Full log
Message #83 received at 61350 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
>> So would you buy a very fast car that only explodes 10% of the time :-)
>> I think that these kinds of features should be opt-in, at least until
>> one is more sure of their stability. Here, this looks like an unstable
>> feature.
>
> 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?
>> I understand you appreciate this feature and it has advantages
>> elsewhere. But I we can recognize that, as things stand, it is a
>> non-essential performance optimization that wrecks Eglot functionally.
>
> 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. I could use Eglot over Tramp
with decent performance (although this is a local-to-local in disguise).
I wonder what Thomas has to say about performance with a real remote
server when he turns off ControlMaster.
Of course I do understand that it's a very sought after performance
optimization. Doesn't seem to be quite finished, but that's just MHO.
> settings in ~/.ssh/config shall apply. And a new value, say `suppress',
> shall suppress this feature even if enabled in ~/.ssh/config.
>
> I'll try to implement something along this line.
Thanks. I think that is a good start. But can Eglot or the user
somehow set 'suppress' for connections "motivated" by Eglot, i.e. M-x
eglot in some remote file? How?
João
This bug report was last modified 2 years and 49 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.