From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#61748: 27.2; Eglot should use shell-file-name when launching the language server for a remote file Date: Thu, 02 Mar 2023 10:56:22 +0000 Message-ID: <877cvz8lrd.fsf@gmail.com> References: <87sfeqq8z5.fsf@gmail.com> <75486564.6945596.1677592772065.JavaMail.root@zimbra60-e10.priv.proxad.net> <87r0u9devu.fsf@gmx.de> <87bkld6ctm.fsf@gmx.de> <87356p6b7g.fsf@gmx.de> <878rgfecra.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37176"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: jeberger@free.fr, 61748@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 02 11:55:10 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pXgac-0009XP-P5 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Mar 2023 11:55:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pXgaW-00024f-88; Thu, 02 Mar 2023 05:55:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXgaU-00024W-NL for bug-gnu-emacs@gnu.org; Thu, 02 Mar 2023 05:55:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pXgaU-00038z-A7 for bug-gnu-emacs@gnu.org; Thu, 02 Mar 2023 05:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pXgaU-0001W4-44 for bug-gnu-emacs@gnu.org; Thu, 02 Mar 2023 05:55:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Mar 2023 10:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61748 X-GNU-PR-Package: emacs Original-Received: via spool by 61748-submit@debbugs.gnu.org id=B61748.16777544765794 (code B ref 61748); Thu, 02 Mar 2023 10:55:02 +0000 Original-Received: (at 61748) by debbugs.gnu.org; 2 Mar 2023 10:54:36 +0000 Original-Received: from localhost ([127.0.0.1]:55930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXga4-0001VO-0d for submit@debbugs.gnu.org; Thu, 02 Mar 2023 05:54:36 -0500 Original-Received: from mail-wr1-f52.google.com ([209.85.221.52]:43764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXga2-0001VA-IR for 61748@debbugs.gnu.org; Thu, 02 Mar 2023 05:54:35 -0500 Original-Received: by mail-wr1-f52.google.com with SMTP id e13so4562026wro.10 for <61748@debbugs.gnu.org>; Thu, 02 Mar 2023 02:54:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677754468; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1pK8qX+Qqi2dUNNGZcuYRfaydPJYswAtn6FIAZCs6YA=; b=GK89sAir7wc3wfK998j+JYG6zbJsCM/Jxd7Dmr1w34Ekyk2/PslksWzO7VhLTOej92 BP+iQDwBuQdKfmKV7mpDa+vDHPf4NdeCW6zXJiAqyTpoVrgnd8kz4+XGONtQ2QQ870O4 xRDNAFcrVJQCybDqATzA8jG7iN4Z5ynvG+PmmYKvWX96QTKsXHMwKqJLX9j9rZHeWYNR 6lLZQwjwEw4sh4oiF96VxMjyAkmg29ZRLpEkzROgJHAf0Vaip7dRHGl/wY/K7gLorLqE U9VA058nMVWIhXN7rnhBUCvl05JHFzJos7OzQgty4ZXLt1S6RM5XIwXhH9VIxyVZ9cee RL8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677754468; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=1pK8qX+Qqi2dUNNGZcuYRfaydPJYswAtn6FIAZCs6YA=; b=wVxHgft6n89jwZUmSItqL821MJ81p/0/ir1q/tjURBYemuHDFKSrho8P4MblfXS14g 1sDiAF+S+WAbcfh7bnKyBbJ7cjsTwBntf1C2UOr0hQuS6aEGjqUckqnA03NV0loO5u6M 7o0ZGnZdgIzJSfjimXrzGDjq/tj/d7j83F3Ze/nj0jpx9PCoXURHJehS6F+8owfkc4zM ATjK44sOypEgBtGuQiYLIbQHh7FU7i/Oy+hiCupPmy/rQHkcjwY0CTUWKHaDaY/SwP6c oEMy6ChUyYRasIHCTFldCB8H1BrBgO7kUkzD+bIzhMvNusHn0zs01jBrRK7f8rOD+PcC sgNg== X-Gm-Message-State: AO0yUKUEQtNWJ5xcK5tNBhEk0BhBiBcbJUKPJiqZe3osJrb7Tgz0icYC pmfVTkGG2Hq8lTcMmcLM82EFuwlqxsg= X-Google-Smtp-Source: AK7set/j+vHZ1y5YvV87Od9xpcsWqvOU27/N42beD1NIUtvS4MnDaz4ASYYm0ZDyUdrVw5NWxVPy0g== X-Received: by 2002:a5d:6a8e:0:b0:2c7:145c:68f2 with SMTP id s14-20020a5d6a8e000000b002c7145c68f2mr7292184wru.58.1677754467914; Thu, 02 Mar 2023 02:54:27 -0800 (PST) Original-Received: from krug (87-196-72-142.net.novis.pt. [87.196.72.142]) by smtp.gmail.com with ESMTPSA id t1-20020a5d6a41000000b002c70a68111asm15196741wrw.83.2023.03.02.02.54.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Mar 2023 02:54:27 -0800 (PST) In-Reply-To: <878rgfecra.fsf@gmx.de> (Michael Albinus's message of "Thu, 02 Mar 2023 10:14:17 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:257132 Archived-At: Michael Albinus 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=C3=A3o