Michael Albinus <michael.albi...@gmx.de> writes: >> You still focus on tramp-set-remote-path. As said in my last message, we >> need also to touch tramp-get-re mote-path. >> >> Have you tested (exec-path) with your patches in play? I didn't, but I >> elieve we need to do something here as well.
I will check tramp-get-remote-path and will look into testing (exec-path), I was hoping to get your feedback first. > My approach is different. When tramp-remote-path is > '(tramp-own-remote-path), I intend to check nothing, and to set > NOTHING. The remote $PATH is already proper per definition. Yes, both my patches are variations on a very similar approach, which is to skip the checks and the setting when two criteria are fullfilled: 1. tramp-remote-path is '(tramp-own-remote-path), and 2. tramp-optimize-remote-path is set to nil. The reasons I think tramp-optimize-remote-path should exist are: - provide backward compatibility for users who have been expecting the checks to always be there - provide the ability to disable them for all possible values of tramp-remote-path, and not just when '(tramp-own-remote-path)
