bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#61748: 27.2; Eglot should use shell-file-name when launching the lan


From: João Távora
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@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]