GNU bug report logs - #76955
30.1; php-ts-mode-php-executable default path may not match remote path

Previous Next

Full log

View this message in rfc822 format

From: Morgan Willcock <morgan <at> ice9.digital>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: v.pupillo <at> gmail.com, 76955 <at> debbugs.gnu.org
Subject: bug#76955: 30.1; php-ts-mode-php-executable default path may not match remote path
Date: Sat, 15 Mar 2025 13:07:54 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Morgan Willcock <morgan <at> ice9.digital>
>> Cc: Vincenzo Pupillo <v.pupillo <at> gmail.com>,  76955 <at> debbugs.gnu.org
>> Date: Sat, 15 Mar 2025 11:03:40 +0000
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > So I conclude that expecting "php" to be on PATH on remote systems is
>> > a requirement, since nothing else will work reliably enough, and let's
>> > close this discussion at that.
>>
>> I am not sure what you mean by "reliably", but being on PATH is not a
>> requirement to use it.  It will very likely be on PATH, but with some
>> additional configuration of the TRAMP connection it doesn't need to be.
>
> I mean that we should use executable-find for remote directories,
> thus assuming that the program is on PATH on remote systems, and let
> users customize the local value via the user option.

I think this introduces an additional complication if executable-find
finds a binary which is not the one that should be used.

> IOW, the user option should not have effect on remote invocations.

From my perspective as a user of mode, just setting the value to "php"
introduces no additional complexity, works in more places by default
than the current value, and doesn't deviate from how other modes (and
associated executable paths) are managed.

I feel we should probably get input from TRAMP maintainers at this point
- I don't think I can add much more context beyond what I've already
written and I don't want to keep repeating the same points.

-- 
Morgan Willcock

Previous Next

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