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

["João Távora" <joaotavora@gmail.com>]

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

>>> I'll play with it. Perhaps there is a smarter version of it, as you say.
>>
>> Here's another still untested but smarter patch.  Caches fully
>> on until user messes with tramp-remote-path, else immediately
>> flushed.
>
> Just flushing the connection property "remote-path" is not sufficient I
> believe.

I've tested it and it works just fine on my end.  What problems did you
see.

Let me be clear about what i'm attempting to fix, using condensed Emacs
-Q recipes that illustrate what I do during actual sessions.

Before applying my patch, this prints "jdtls", correctly

    ~/Source/Emacs/emacs/src/emacs -Q --batch                \
    -l tramp                                                 \
    --eval '(add-to-list (quote tramp-remote-path) "~/bin")' \
    $REMOTE_FILE                                             \
    --eval '(message "%s" (executable-find "jdtls" t))'

which is fine, of course.  You happened to remember early enough that
the remote host you're going to connect to needs a ~/bin in
tramp-remote-path, so you set that early.

But if you don't remember at the right time, like here:

    ~/Source/Emacs/emacs/src/emacs -Q --batch $REMOTE_FILE   \
    -l tramp                                                 \
    --eval '(add-to-list (quote tramp-remote-path) "~/bin")' \
    --eval '(message "%s" (executable-find "jdtls" t))'

It prints nil.

I find this very confusing, and lost many hours to it.  I expect
'tramp-remote-path' to work like most other variables: set values with
M-:, custom-set-variable, etc.  Then verify the settings work, then
maybe put that in my init file.

After my patch, both invocations print "jdtls".  Can't see how it
doesn't improve things.  Is trivial to understand and has no performance
drawbacks.  It relieves users from keeping a mental model of Tramp's
caches.

> You still must cleanup the process. This is because the remote
> PATH environment is set when starting the process.

This is doesn't differ from local PATH vs local exec-path.  You add
things to exec-path that affect `executable-find`, but don't affect
PATH.

> And I fail to understand, why connection-local variables don't serve the
> purpose. They are described wrt to the remote path in
>
> (info "(tramp) Remote programs")

How am I to use "connection-local variables" here?  Reading the manual
it seems I add multiple setting to my configuration for every host I
connect to.  Like dir-local variables.  That's fine, but I don't know
those hosts and settings in advance.  And if I wanted to change my
configuration, setting tramp-remote-path early on in my .emacs _already_
works.  Which is exactly the confusing part.

> If this isn't sufficient, we must improve this, instead of introducing
> another mechanism.

I'm not proposing new mechanisms or changes to existing ones.  Simply to
invalidate a cache value when there are changes to the source of truth
whence said cached value came.  IME, this is pretty standard thing to
do.

> And remember, remote processes are not designed to be
> as flexible as local processes, where you could simply call
> (setenv "PATH" ...)

I never do that, and I don't want to do that anyway.  I just want
executable-find to not be tricked by some misinvalidated cache.

João