Re: Eglot and Tramp

Re: Eglot and Tramp

[João Távora]

Thanks you very much Michael for the fix to Tramp, Michael.

I'm the discussion switching to emacs-devel.

I've yet to test it out, but do you think it's possible to make
this fix available in Emacs 27, given that the bug was found
there?  I'm afraid we won't be able to advertise Tramp support
in Eglot soon unless you do this.

This is of course assuming that this fix does fix Eglot's attempts
to use Tramp (which I or someone else still has to confirm).

Thanks,
João

On Fri, Jun 19, 2020 at 2:18 PM Michael Albinus <michael.albinus@gmx.de> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> > Hi Michael,
>
> Hi João,
>
> > [ Felipe, I don't subscribe to tramp-devel, so please next time CC me in
> > these emails so that we try to fill in the blanks when there's something
> > not quite clear ]
>
> Or write an Emacs bug report, if several packages are involved.
>
> > Thanks for looking into this.  I fully understand avoiding the complex
> > setup, so I've put together a small Elisp program that you can run from
> > Emacs -Q.
>
> Thanks! It was very helpful. I've pushed a fix to master, which ought to
> cure this.
>
> > There are two tests you can do within eglot-tramp.el: one using the
> > usual "cat" program, the other one is more interesting and requires that
> > you download "clangd", an LSP server ('sudo apt install clangd' will
> > probably do).
> >
> > But if you don't want to do that (download "clangd"), any program that
> > spits out stdout and stderr should have the same effect.
>
> I've tried both test cases. The clangd variant was a little bit tricky,
> because I had to use Fedora's snap installer, and to adapt my remote
> $PATH. And the installed clangd didn't return proper messages to my
> eyes, but it returned stdout and stderr - all what I need for testing :-)
>
> Could you pls check?
>
> > João
>
> Best regards, Michael.



-- 
João Távora

Re: Eglot and Tramp

[Michael Albinus]

João Távora <joaotavora@gmail.com> writes:

Hi João,

> I've yet to test it out, but do you think it's possible to make
> this fix available in Emacs 27, given that the bug was found
> there?  I'm afraid we won't be able to advertise Tramp support
> in Eglot soon unless you do this.

Definitely not in Emacs 27.1. This is in pretest, and I don't want to
err out this release.

There are already *many* Tramp fixes which are on hold for Emacs 27. I
collect them in the Tramp 2.4 branch of the Tramp repository, and I will
merge all of them to the emacs-27 branch once Emacs 27.1 has been
released.

But don't worry: the Tramp 2.4 release is kept up-to-date in GNU
ELPA. Once you can confirm that the change works for you, I'll backport it.

> This is of course assuming that this fix does fix Eglot's attempts
> to use Tramp (which I or someone else still has to confirm).

Please tell me so. The next Tramp 2.4 release in ELPA is roughly
scheduled for end of June, 10 days from now.

> Thanks,
> João

Best regards, Michael.

Re: Eglot and Tramp

[João Távora]

On Fri, Jun 19, 2020 at 2:44 PM Michael Albinus <michael.albinus@gmx.de> wrote:
> João Távora <joaotavora@gmail.com> writes:

> But don't worry: the Tramp 2.4 release is kept up-to-date in GNU
> ELPA. Once you can confirm that the change works for you, I'll backport it.

That's great.  It means that as long as Eglot, which is also a GNU ELPA
package, depends on that particular version of Tramp, users who install
it from that source (using package.el) will benefit from the fix. Can you
confirm?

> Please tell me so. The next Tramp 2.4 release in ELPA is roughly
> scheduled for end of June, 10 days from now.

Noted.  Felipe, you may want to beat me to it if you still have the
energy for this.

João

Re: Eglot and Tramp

[Michael Albinus]

João Távora <joaotavora@gmail.com> writes:

> On Fri, Jun 19, 2020 at 2:44 PM Michael Albinus <michael.albinus@gmx.de> wrote:
>> João Távora <joaotavora@gmail.com> writes:
>
>> But don't worry: the Tramp 2.4 release is kept up-to-date in GNU
>> ELPA. Once you can confirm that the change works for you, I'll backport it.
>
> That's great.  It means that as long as Eglot, which is also a GNU ELPA
> package, depends on that particular version of Tramp, users who install
> it from that source (using package.el) will benefit from the fix. Can you
> confirm?

Yes. You could add (tramp "2.4.4") to your Package-Requires: header,
this will be the next version in GNU ELPA. However, this would mean a
dependency for all Eglot users, even if they are not interested in
Tramp. Hmm.

> João

Best regards, Michael.

Re: Eglot and Tramp

[João Távora]

On Fri, Jun 19, 2020 at 3:43 PM Michael Albinus <michael.albinus@gmx.de> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> > On Fri, Jun 19, 2020 at 2:44 PM Michael Albinus <michael.albinus@gmx.de> wrote:
> >> João Távora <joaotavora@gmail.com> writes:
> >
> >> But don't worry: the Tramp 2.4 release is kept up-to-date in GNU
> >> ELPA. Once you can confirm that the change works for you, I'll backport it.
> >
> > That's great.  It means that as long as Eglot, which is also a GNU ELPA
> > package, depends on that particular version of Tramp, users who install
> > it from that source (using package.el) will benefit from the fix. Can you
> > confirm?
>
> Yes. You could add (tramp "2.4.4") to your Package-Requires: header,
> this will be the next version in GNU ELPA. However, this would mean a
> dependency for all Eglot users, even if they are not interested in
> Tramp. Hmm.

What Hmm? :-) Emacs users who are not "interested in Tramp" still get
it, too, right? Or does Tramp 2.4.4 come with some kind of potential
built-in annoyance? :-D

João

Re: Eglot and Tramp

[Michael Albinus]

João Távora <joaotavora@gmail.com> writes:

>> Yes. You could add (tramp "2.4.4") to your Package-Requires: header,
>> this will be the next version in GNU ELPA. However, this would mean a
>> dependency for all Eglot users, even if they are not interested in
>> Tramp. Hmm.
>
> What Hmm? :-) Emacs users who are not "interested in Tramp" still get
> it, too, right? Or does Tramp 2.4.4 come with some kind of potential
> built-in annoyance? :-D

No annoyance. But a user of Emacs 26.3 has Tramp 2.3.5 built-in. Because
of Eglot, Tramp 2.4.4 would be installed for her from GNU ELPA, w/o
having asked for.

> João

Best regards, Michael.

Re: Eglot and Tramp

[João Távora]

[sorry for the duplicate, Michael]

Fri, Jun 19, 2020 at 3:54 PM Michael Albinus <michael.albinus@gmx.de> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> >> Yes. You could add (tramp "2.4.4") to your Package-Requires: header,
> >> this will be the next version in GNU ELPA. However, this would mean a
> >> dependency for all Eglot users, even if they are not interested in
> >> Tramp. Hmm.
> >
> > What Hmm? :-) Emacs users who are not "interested in Tramp" still get
> > it, too, right? Or does Tramp 2.4.4 come with some kind of potential
> > built-in annoyance? :-D
>
> No annoyance. But a user of Emacs 26.3 has Tramp 2.3.5 built-in. Because
> of Eglot, Tramp 2.4.4 would be installed for her from GNU ELPA, w/o
> having asked for.

Well, this user did ask for Eglot.  He will also get an updated
xref.el, project.el eldoc.el, flymake.el as already happens.  I'm
afraid this is just how inter-package dependencies work.

As long as Tramp 2.4.4 is (mostly) backward compatible to 2.3.5's uses...
there should be no (little) problem.

João

Re: Eglot and Tramp

[Michael Albinus]

João Távora <joaotavora@gmail.com> writes:

Hi João,

>> No annoyance. But a user of Emacs 26.3 has Tramp 2.3.5 built-in. Because
>> of Eglot, Tramp 2.4.4 would be installed for her from GNU ELPA, w/o
>> having asked for.
>
> Well, this user did ask for Eglot.  He will also get an updated
> xref.el, project.el eldoc.el, flymake.el as already happens.  I'm
> afraid this is just how inter-package dependencies work.

The point is that this Tramp upgrade is not mandatory. Only if a user
wants to apply Eglot remotely. I'm the last one who would say a Tramp
upgrade is bad :-) But a Tramp upgrade w/o a reason?

> As long as Tramp 2.4.4 is (mostly) backward compatible to 2.3.5's uses...
> there should be no (little) problem.

It's backward compatible.

> João

Best regards, Michael.

Re: Eglot and Tramp

[João Távora]

On Fri, Jun 19, 2020 at 5:28 PM Michael Albinus <michael.albinus@gmx.de> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> Hi João,
>
> >> No annoyance. But a user of Emacs 26.3 has Tramp 2.3.5 built-in. Because
> >> of Eglot, Tramp 2.4.4 would be installed for her from GNU ELPA, w/o
> >> having asked for.
> >
> > Well, this user did ask for Eglot.  He will also get an updated
> > xref.el, project.el eldoc.el, flymake.el as already happens.  I'm
> > afraid this is just how inter-package dependencies work.
>
> The point is that this Tramp upgrade is not mandatory. Only if a user
> wants to apply Eglot remotely. I'm the last one who would say a Tramp
> upgrade is bad :-) But a Tramp upgrade w/o a reason?

Yes, but in that vein of thinking then Tramp shouldn't be bundled
with Emacs too. There are lots of things we can do with Emacs
that don't require Tramp.  But some of them do, and so we bundle
Tramp.

And the same thing if we substitute Tramp for any feature X.

João

Re: Eglot and Tramp

[João Távora]

On Fri, Jun 19, 2020 at 5:30 PM João Távora <joaotavora@gmail.com> wrote:
>
> On Fri, Jun 19, 2020 at 5:28 PM Michael Albinus <michael.albinus@gmx.de> wrote:
> >
> > João Távora <joaotavora@gmail.com> writes:
> >
> > Hi João,
> >
> > >> No annoyance. But a user of Emacs 26.3 has Tramp 2.3.5 built-in. Because
> > >> of Eglot, Tramp 2.4.4 would be installed for her from GNU ELPA, w/o
> > >> having asked for.
> > >
> > > Well, this user did ask for Eglot.  He will also get an updated
> > > xref.el, project.el eldoc.el, flymake.el as already happens.  I'm
> > > afraid this is just how inter-package dependencies work.
> >
> > The point is that this Tramp upgrade is not mandatory. Only if a user
> > wants to apply Eglot remotely. I'm the last one who would say a Tramp
> > upgrade is bad :-) But a Tramp upgrade w/o a reason?
>
> Yes, but in that vein of thinking then Tramp shouldn't be bundled
> with Emacs too. There are lots of things we can do with Emacs
> that don't require Tramp.  But some of them do, and so we bundle
> Tramp.
>
> And the same thing if we substitute Tramp for any feature X.

Of course, we do take something similar in consideration regarding
the _loading_ of X.  For that, we have just-in-time "autoloads".  But
we don't have just-in-time "autoinstalls" yet.

João

Re: Eglot and Tramp

[Michael Albinus]

João Távora <joaotavora@gmail.com> writes:

Hi João,

> Of course, we do take something similar in consideration regarding
> the _loading_ of X.  For that, we have just-in-time "autoloads".  But
> we don't have just-in-time "autoinstalls" yet.

That's exactly my point. We have no mean to say in eglot.el "if you use
Tramp, please ensure that you have at least Tramp 2.4.4. Otherwise,
autoinstall it from GNU ELPA."

> João

Best regards, Michael.

Re: Eglot and Tramp

[João Távora]

On Fri, Jun 19, 2020 at 5:39 PM Michael Albinus <michael.albinus@gmx.de> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> Hi João,
>
> > Of course, we do take something similar in consideration regarding
> > the _loading_ of X.  For that, we have just-in-time "autoloads".  But
> > we don't have just-in-time "autoinstalls" yet.
>
> That's exactly my point. We have no mean to say in eglot.el "if you use
> Tramp, please ensure that you have at least Tramp 2.4.4. Otherwise,
> autoinstall it from GNU ELPA."

But it's the same with Flymake, or Project or Xref or any other feature
that Eglot uses. Thought those features are slightly more essential
to Eglot's central promise (though not completely).

But actually, we do.  I mean, Eglot could check Tramp's version at
run-time and give exactly that warning you suggest.  But my
question is: what benefit would that produce?

I practice, what kind of remotely adverse impact do you
expect from installing 2.4.4?  Is it a very large download? Does
the compilation take very long? Something else?

Re: Eglot and Tramp

[Michael Albinus]

João Távora <joaotavora@gmail.com> writes:

Hi João,

> I practice, what kind of remotely adverse impact do you
> expect from installing 2.4.4?  Is it a very large download? Does
> the compilation take very long? Something else?

I don't expect any adverse impact. It's just the "principle of least
surprise". Personally, I dislike software which installs something else
w/o any need.

But you're right, likely nobody will complain in practice. So pls ignore
my mumbling :-)

Best regards, Michael.

Re: Eglot and Tramp

[João Távora]

On Fri, Jun 19, 2020 at 6:30 PM Michael Albinus <michael.albinus@gmx.de> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> Hi João,
>
> > I practice, what kind of remotely adverse impact do you
> > expect from installing 2.4.4?  Is it a very large download? Does
> > the compilation take very long? Something else?
>
> I don't expect any adverse impact. It's just the "principle of least
> surprise". Personally, I dislike software which installs something else
> w/o any need.

Actually, I agree.  I personally use the latest Emacs 28 to avoid these
kinds of package.el woes (and to keep developing on the packages
themselves).

> But you're right, likely nobody will complain in practice. So pls ignore
> my mumbling :-)

You're at least a "data point" in my decision. I want that users at least
have the option of running Eglot remotely over Tramp on Emacs 27.1.
There are options for that.

1. The package-requires way.  Seems to be "the future";
2. You bring that bugfix to Emacs 27;
3. I dont' do anything, wait for bug reports and tell people to install a newer
Tramp;
4. I put in an automated check in eglot.el that does the same as 3.

João

Re: Eglot and Tramp

[Dmitry Gutov]

On 19.06.2020 20:36, João Távora wrote:
> 4. I put in an automated check in eglot.el that does the same as 3.

A runtime check sounds best to me, personally.

Re: Eglot and Tramp

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> 4. I put in an automated check in eglot.el that does the same as 3.
>
> A runtime check sounds best to me, personally.

Likely yes. But there won't be a feature or Lisp object to check for the
given solution in Tramp. You can only check the Tramp version.

Best regards, Michael.

eglot and tramp

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

Hi

I'm looking for some advice on using eglot in a remote TRAMP editing
session. I have a couple of scenarios where I'd need to access a VM and
edit Python code residing inside. Having a Python LSP that can help me in
this use case would be really great.

Since there is nothing in the eglot manual about this scenario, I'm asking
for enlightenment here

Thanks a ton, /PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 971 bytes --]

Re: eglot and tramp

[Brian Cully via Emacs development discussions.]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> I'm looking for some advice on using eglot in a remote TRAMP editing
> session. I have a couple of scenarios where I'd need to access a VM and
> edit Python code residing inside. Having a Python LSP that can help me in
> this use case would be really great.
>
> Since there is nothing in the eglot manual about this scenario, I'm asking
> for enlightenment here

As long as the language server is installed on the remote, it should
Just Work™.

You may need to add ‘'tramp-own-remote-path’ to ‘tramp-remote-path’,
depending on where the LSP is installed, however.

-bjc

Re: eglot and tramp

[Michael Albinus]

Brian Cully via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

Hi,

>> I'm looking for some advice on using eglot in a remote TRAMP editing
>> session. I have a couple of scenarios where I'd need to access a VM and
>> edit Python code residing inside. Having a Python LSP that can help me in
>> this use case would be really great.
>>
>> Since there is nothing in the eglot manual about this scenario, I'm asking
>> for enlightenment here
>
> As long as the language server is installed on the remote, it should
> Just Work™.
>
> You may need to add ‘'tramp-own-remote-path’ to ‘tramp-remote-path’,
> depending on where the LSP is installed, however.

It is on my TODO to check how well Tramp is integrated with eglot. Great
to hear that it seems to work flawless, but I believe there might be
some hints for performance improvement, like setting
"direct-async-process" connection property.

When time permits I'll go through this, and I might contribute some few
words to the eglot manual.

> -bjc

Best regards, Michael.

Re: eglot and tramp

[Brian Cully via Emacs development discussions.]

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

> It is on my TODO to check how well Tramp is integrated with eglot. Great
> to hear that it seems to work flawless, but I believe there might be
> some hints for performance improvement, like setting
> "direct-async-process" connection property.

I wouldn't go so far as to say "flawlessly". It does often run into the
"forbidden re-entrant call to Tramp" problem, but that's not unique to
Eglot, and it doesn't seem to cause any problems other than an annoying
message periodically in the echo area.

Otherwise it works pretty well. I've been using it like this for years,
and am pretty happy with it.

-bjc

Re: eglot and tramp

[Michael Albinus]

Brian Cully <bjc@spork.org> writes:

Hi Brian,

>> It is on my TODO to check how well Tramp is integrated with eglot. Great
>> to hear that it seems to work flawless, but I believe there might be
>> some hints for performance improvement, like setting
>> "direct-async-process" connection property.
>
> I wouldn't go so far as to say "flawlessly". It does often run into the
> "forbidden re-entrant call to Tramp" problem, but that's not unique to
> Eglot, and it doesn't seem to cause any problems other than an annoying
> message periodically in the echo area.

Yes, this is an open problem. I hoped to fix it by using threads in
Tramp, but this has other problems.

> Otherwise it works pretty well. I've been using it like this for years,
> and am pretty happy with it.

Great! Since you are a regular eglot+Tramp user, could I ask you for a
test?

I assume you are using Tramp with ssh or scp. If you also don't use a
password (for example via public key authentication), please try the
following setting:

--8<---------------cut here---------------start------------->8---
(add-to-list 'tramp-connection-properties
             (list (regexp-quote "/ssh:user@host:")
                   "direct-async-process" t))
--8<---------------cut here---------------end--------------->8---

"/ssh:user@host:" must be adapted of course, and you must set this prior
opening a connection to this remote path. This should give you better
performance when starting the language server.

Does it work for you? Does it make a difference?

> -bjc

Best regards, Michael.

Re: eglot and tramp

[Brian Cully via Emacs development discussions.]

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

> Great! Since you are a regular eglot+Tramp user, could I ask you for a
> test?
>
> I assume you are using Tramp with ssh or scp. If you also don't use a
> password (for example via public key authentication), please try the
> following setting:
>
> --8<---------------cut here---------------start------------->8---
> (add-to-list 'tramp-connection-properties
>              (list (regexp-quote "/ssh:user@host:")
>                    "direct-async-process" t))
> --8<---------------cut here---------------end--------------->8---
>
> "/ssh:user@host:" must be adapted of course, and you must set this prior
> opening a connection to this remote path. This should give you better
> performance when starting the language server.

I use eglot+Tramp with various containers (nspawn, docker, podman),
which don't support the ‘tramp-direct-async’ flag, so I'm not sure how
helpful this testing would be.

I know we've spoken about that flag before, and I came away from those
discussions with the impression that those methods should not support
direct-async, but I'm unsure why. I have only skimmed the relevant code,
but it seems like there shouldn't be a problem with supporting
direct-async on the container methods. Is there some danger I should be
aware of?

If it's safe enough, I'd be happy to flag support for direct-async in
the methods and do the above test.

WDYT?

-bjc

Re: eglot and tramp

[Michael Albinus]

Brian Cully <bjc@spork.org> writes:

Hi Brian,

>> Great! Since you are a regular eglot+Tramp user, could I ask you for a
>> test?
>>
>> I assume you are using Tramp with ssh or scp. If you also don't use a
>> password (for example via public key authentication), please try the
>> following setting:
>>
>> --8<---------------cut here---------------start------------->8---
>> (add-to-list 'tramp-connection-properties
>>              (list (regexp-quote "/ssh:user@host:")
>>                    "direct-async-process" t))
>> --8<---------------cut here---------------end--------------->8---
>>
>> "/ssh:user@host:" must be adapted of course, and you must set this prior
>> opening a connection to this remote path. This should give you better
>> performance when starting the language server.
>
> I use eglot+Tramp with various containers (nspawn, docker, podman),
> which don't support the ‘tramp-direct-async’ flag, so I'm not sure how
> helpful this testing would be.

Good point. I haven't checked docker, podman and friends yet whether
they do suuport direct async processes. Short check: they don't yet. I
will work on adding this feature in Tramp.

> If it's safe enough, I'd be happy to flag support for direct-async in
> the methods and do the above test.

I'll come back to you when Tramp is prepared.

> -bjc

Best regards, Michael.

Re: eglot and tramp

[Michael Albinus]

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]

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

Hi Brian,

>>> Great! Since you are a regular eglot+Tramp user, could I ask you for a
>>> test?
>>>
>>> I assume you are using Tramp with ssh or scp. If you also don't use a
>>> password (for example via public key authentication), please try the
>>> following setting:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> (add-to-list 'tramp-connection-properties
>>>              (list (regexp-quote "/ssh:user@host:")
>>>                    "direct-async-process" t))
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> "/ssh:user@host:" must be adapted of course, and you must set this prior
>>> opening a connection to this remote path. This should give you better
>>> performance when starting the language server.
>>
>> I use eglot+Tramp with various containers (nspawn, docker, podman),
>> which don't support the ‘tramp-direct-async’ flag, so I'm not sure how
>> helpful this testing would be.
>
> Good point. I haven't checked docker, podman and friends yet whether
> they do suuport direct async processes. Short check: they don't yet. I
> will work on adding this feature in Tramp.
>
>> If it's safe enough, I'd be happy to flag support for direct-async in
>> the methods and do the above test.
>
> I'll come back to you when Tramp is prepared.

I gave it a shot. Appended is a patch, which improves
tramp-handle-make-process in tramp.el. The method specifications in
tramp-container.el are extended by the line

--8<---------------cut here---------------start------------->8---
		(tramp-direct-async (,tramp-default-remote-shell "-c"))
--8<---------------cut here---------------end--------------->8---

Locally, I have tested it with the methods "docker" and "kubernetes", it
seems to work. I couldn't test with "podman", because I haven't such a
system just now.

For "nspawn" I cannot say anything, I don't use it. Perhaps it is
sufficient to add a similar line in its tramp-methods specification,
don't know. You as author might know it better. And if it works
sufficiently, we might also think about integrating it into
tramp-container.el. But this would be another story.

>> -bjc

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 2232 bytes --]

diff --git a/lisp/tramp-container.el b/lisp/tramp-container.el
index 0879d6f1..7b942532 100644
--- a/lisp/tramp-container.el
+++ b/lisp/tramp-container.el
@@ -163,6 +163,7 @@ see its function help for a description of the format."
                                    ("-u" "%u")
                                    ("%h")
 			           ("%l")))
+		(tramp-direct-async (,tramp-default-remote-shell "-c"))
                 (tramp-remote-shell ,tramp-default-remote-shell)
                 (tramp-remote-shell-login ("-l"))
                 (tramp-remote-shell-args ("-i" "-c"))))
@@ -174,6 +175,7 @@ see its function help for a description of the format."
                                    ("-u" "%u")
                                    ("%h")
 			           ("%l")))
+		(tramp-direct-async (,tramp-default-remote-shell "-c"))
                 (tramp-remote-shell ,tramp-default-remote-shell)
                 (tramp-remote-shell-login ("-l"))
                 (tramp-remote-shell-args ("-i" "-c"))))
@@ -186,6 +188,7 @@ see its function help for a description of the format."
                                    ("--")
 			           ("%l")))
 		(tramp-config-check tramp-kubernetes--current-context-data)
+		(tramp-direct-async (,tramp-default-remote-shell "-c"))
                 (tramp-remote-shell ,tramp-default-remote-shell)
                 (tramp-remote-shell-login ("-l"))
                 (tramp-remote-shell-args ("-i" "-c"))))
diff --git a/lisp/tramp.el b/lisp/tramp.el
index f20a1fc3..003912f8 100644
--- a/lisp/tramp.el
+++ b/lisp/tramp.el
@@ -4836,7 +4836,14 @@ substitution.  SPEC-LIST is a list of char/value pairs used for
 	       (command
 	        (append
 		 `("cd" ,(tramp-shell-quote-argument localname) "&&" "(" "env")
-		 env `(,command ")"))))
+		 env `(,command ")")))
+		;; Add remote shell if needed.
+	       (command
+		(if (consp (tramp-get-method-parameter v 'tramp-direct-async))
+		    (append
+		     (tramp-get-method-parameter v 'tramp-direct-async)
+ 		     `(,(mapconcat #'identity command " ")))
+		  command)))

 	  ;; Check for `tramp-sh-file-name-handler', because something
 	  ;; is different between tramp-sh.el, and tramp-adb.el or

Re: eglot and tramp

[Brian Cully via Emacs development discussions.]

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

> Locally, I have tested it with the methods "docker" and "kubernetes", it
> seems to work. I couldn't test with "podman", because I haven't such a
> system just now.

I've applied your patch, and will get back to you after I've used it for
a few days. So far, so good, though. Is there any behavior I should be
paying special attention to?

> For "nspawn" I cannot say anything, I don't use it. Perhaps it is
> sufficient to add a similar line in its tramp-methods specification,
> don't know. You as author might know it better. And if it works
> sufficiently, we might also think about integrating it into
> tramp-container.el. But this would be another story.

If nspawn-style containers are desirable in mainline Tramp, I can put
together a patch for you when I get some cycles.

-bjc

Re: eglot and tramp

[Michael Albinus]

Brian Cully <bjc@spork.org> writes:

Hi Brian,

>> Locally, I have tested it with the methods "docker" and "kubernetes", it
>> seems to work. I couldn't test with "podman", because I haven't such a
>> system just now.
>
> I've applied your patch, and will get back to you after I've used it for
> a few days. So far, so good, though. Is there any behavior I should be
> paying special attention to?

Hmm, does it show better performance when accessing an lsp server?

Otherwise, special restrictions for Tramp's direct async processes are
domented at (info "(tramp)Improving performance of asynchronous remote processes").

>> For "nspawn" I cannot say anything, I don't use it. Perhaps it is
>> sufficient to add a similar line in its tramp-methods specification,
>> don't know. You as author might know it better. And if it works
>> sufficiently, we might also think about integrating it into
>> tramp-container.el. But this would be another story.
>
> If nspawn-style containers are desirable in mainline Tramp, I can put
> together a patch for you when I get some cycles.

Yes, it would be welcome in tramp-container.el. Even if it doesn't
support direct-async (yet).

> -bjc

Best regards, Michael.

Re: eglot and tramp

[Brian Cully via Emacs development discussions.]

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

> Hmm, does it show better performance when accessing an lsp server?

I haven't noticed any particular difference in speed. But I didn't find
eglot in a container to be noticeably slow before, either. My computer
is a beast, and container execution is basically native anyway.

>> If nspawn-style containers are desirable in mainline Tramp, I can put
>> together a patch for you when I get some cycles.
>
> Yes, it would be welcome in tramp-container.el. Even if it doesn't
> support direct-async (yet).

I'll add it to my list and let you know when it's ready.

-bjc

Re: eglot and tramp

[Michael Albinus]

Brian Cully <bjc@spork.org> writes:

Hi Brian,

> I haven't noticed any particular difference in speed. But I didn't find
> eglot in a container to be noticeably slow before, either. My computer
> is a beast, and container execution is basically native anyway.

Bad for testing :-)

>>> If nspawn-style containers are desirable in mainline Tramp, I can put
>>> together a patch for you when I get some cycles.
>>
>> Yes, it would be welcome in tramp-container.el. Even if it doesn't
>> support direct-async (yet).
>
> I'll add it to my list and let you know when it's ready.

Thanks!

> -bjc

Best regards, Michael.