GNU bug report logs - #61748
27.2; Eglot should use shell-file-name when launching the language server for a remote file

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: jeberger <at> free.fr
Cc: Michael Albinus <michael.albinus <at> gmx.de>, 61748 <at> debbugs.gnu.org
Subject: bug#61748: 27.2; Eglot should use shell-file-name when launching the language server for a remote file
Date: Tue, 28 Feb 2023 15:07:43 +0000

On Tue, Feb 28, 2023 at 2:49 PM <jeberger <at> free.fr> wrote:

> > For me, a change to a variable should take effect immediately,
> > no reboots or restarts.  If you're satisfied with less, suit yourself
> > (maybe you're on M$ windows?).
> >
> My main platform is Linux, I only use W$ at work because I have to.

Heyy, I know the feeling ;-)

> But on either platform, I don't expect changes to the environment to be
> picked by child processes or connections that were started before the
> change.

Hmmm.  I do.  In Eglot, I certainly strive to allow this.
eglot-managed-mode-hook is an exception, but a self-documenting one.
I don't know of many more exceptions (there could be).

And especially in Tramp, I would expect to, because those processes
are IMHO implementation details that an end-user shouldn't concern
herself with.  In Eglot there's a user-visible concept of
"Eglot-management session".  In Tramp, unless you start looking
at funny named buffers in your buffer list, there isn't this
visibility of the connection to the user (and IMO there shouldn't be).

> > > 1. When told that the language server is `rust-analyzer`, Eglot
> > > fails
> > Patches welcome.  Patches that remove code and don't break anything
> > even more welcome.  The patch you sent is insufficient, by your own
> > admission.  And Eli didn't like it either.
> >
> Here you go:
>
> ==============================8<------------------------------
> --- a/eglot.el  2023-02-28 15:38:01.161316788 +0100
> +++ b/eglot.el  2023-02-28 15:38:57.445653435 +0100
> @@ -1156,10 +1156,11 @@
>        ;;
>        ;; Not only does this seem like there should be a better way,
>        ;; but it almost certainly doesn’t work on non-unix systems.
> -      (list "sh" "-c"
> -            (string-join (cons "stty raw > /dev/null;"
> -                               (mapcar #'shell-quote-argument contact))
> -             " "))
> +      (with-connection-local-variables
> +       (list shell-file-name shell-command-switch
> +             (string-join (cons "stty raw > /dev/null;"
> +                                (mapcar #'shell-quote-argument contact))
> +                          " ")))
>      contact))
>
>  (defvar-local eglot--cached-server nil
> ------------------------------>8==============================
>
> Note that:
> - I said it was insufficient because it only fixed point 1 not point 2,
>   but that doesn't mean it's not worthwhile (see below for point 2).

OK thanks.  I'm OK with that patch, but I'd rather wait until you
also figure out point 2.  That's because -- I think -- if you can get
executable-find to find the right program in the firsdt place.  Then
we don't need to worry what shell we use to launch the language
server remotely. All things considered, launching the standard "sh"
should be more correct than launching the user's pimped-out custom
shell.

I was even more interested in your idea of removing the need for
that stty in eglot--cmd, which I have to admit I don't understand.
So if you want to try your hand at this, go ahead, too.

João

Previous Next

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