>>> Isn't the idea to use the remote $PATH as-it-is, w/o any change from >>> Tramp side? In this case, we could make it easy, and allow tramp-remote- >>> path to be just t, instead of a list of strings. Tramp wouldn't try >>> to read or set the remote path then. >> >> Perhaps it is even more intuitive, if we allow tramp-remote-path to >> be nil (instead of t). The semantice would be, that it is the same >> as '(tramp-own-remote-path), but w/o any check or setting on the >> remote side. > > I like it, makes sense.
BTW initially I thought the right thing would be to make the path optimizations opt-in rather than opt-out, i.e. make the default value of tramp-optimize-remote-path in my old patch nil rather than t. After learning that the logic to remove non-existing directories dates back to 1999 I wasn't so sure :) https://github.com/emacsmirror/tramp/commit/420a902d Do you know if Tramp has these optimizations for any reason other than the obvious one that it makes remote program search faster? >>>> If you think this can go in, I will follow up with an addition to >>>> the manual and etc/NEWS. Let me know if you'd like me to adapt the >>>> patch in any way or make any other changes. >>> >>> Perhaps you try a patch along this idea? >> >> WDYT? > > I will work on a patch to implement that, thanks! Please see the attached patch. I think it's as simple as that, let me know if I'm missing anything. Wasn't sure if this warrants an entry in etc/NEWS for Emacs.
0001-tramp-sh.el-tramp-open-connection-setup-interactive-.patch
Description: Binary data
