Re: EBrowse obsolete?

[Michael Albinus]

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

> I think there are probably two separate (but somewhat related) issues:
>
> 1. LSP over Tramp is "slow". I'm sure there are things we can do to
> make Tramp faster, especially with "well-behaved" remote hosts. For
> example, maybe Tramp can get more info about a host upon connection
> and then use that to avoid some work later on.

What Tramp can do is to start the remote LSP server
faster. Occasionally, I've been in contact with both the glot and the
lsp-mose people, and I've proposed to use the "direct async process"
feature of Tramp, see

(info "(tramp)Improving performance of asynchronous remote processes")

Personally, I don't use lsp servers, so I have no idea whether this
recommendation got attention.

> 2. LSP over Tramp is "unreliable". I think this is the more-pressing
> issue. It's one thing if a remote request takes longer than expected,
> but another thing entirely if it just fails to work every so
> often. When trying to use Eglot + Tramp on some larger projects, I'd
> get hit with "Forbidden reentrant call of Tramp" every so often,
> which, if memory serves, usually required a bit of poking at Eglot, or
> at least retrying the operation I wanted to do. Maybe this has
> improved since the last time I tried this, but (I think) fixing these
> errors would go a long way towards resolving people's
> complaints. That's probably easier said than done though...

This is a general problem. Whenever a remote operation is triggered
asynchronously, from a timer, a process-filter, or process-sentinel,
this operation can be in conflict with another remote operation just in
process. Tramp detects this, and raises a warning, and refuses to
perform this asynchronous operation. One could instruct Tramp to ignore
this error by

(setq debug-ignored-errors
      (cons 'remote-file-error debug-ignored-errors))

But since the remote operation is not performed, it is likely that the
lsp servers won't work correctly then.