Short answer: Don't edit custom-set-variables form by hand.
Tramp must be loaded for
custom-set-variables to work. Either load tramp before
Or see Michael's answer for a way to tell customize to load tramp first. Note that using
M-x customize-variable RET tramp-remote-path RET creates a correct custom-set-variables entry, of the form suggested by Michael.
The root of the problem seems to be in tramp's custom
###;;;tramp-autoload annotation. This tramp-specific mechanism more or less breaks basic
In normal operation, when you run
customize-set-variables, Emacs does one of two things: if the variable already exists in context it sets it, and if it doesn't, it records the value (using
(set symbol value)), relying on the customize machinery to use that saved value after the variable is declared (through a defcustom).
Then, when Emacs evaluates the corresponding defcustom (when loading the corresponding package, for example), the customize machinery checks whether the symbol being
defcustomed already has a value pending (using
(get symbol 'saved-value)), and sets the symbol to that value if so. If there is no such pending value, it uses the value provided by the defcustom form (the default value).
As an exception, however, the
defcustom implementation also checks that it isn't overriding an already set value. That is, if the variable has already been declared and given a value, then it's value is preserved. To check whether such a default value exists,
default-toplevel-value. If there already is a default value set, it leaves the variable untouched.
The function that does this is
Well, in your case, the problem is precisely this exception. If you open
emacs/lisp/net/tramp-loaddefs.el, you'll see the following:
(defvar tramp-remote-path '(tramp-default-remote-path "/bin" "/usr/bin" "/sbin" "/usr/sbin" "/usr/local/bin" "/usr/local/sbin" "/local/bin" "/local/freeware/bin" "/local/gnu/bin" "/usr/freeware/bin" "/usr/pkg/bin" "/usr/contrib/bin" "/opt/bin" "/opt/sbin" "/opt/local/bin") "\
This is a way to forward declare
tramp-remote-path, but as a side effect it declares and gives a default value to
tramp-remote-path. That's fine as far as
custom-set-variables is concerned, but not as far as
defcustom is concerned. Thus, when the actual
tramp-remote-path is loaded, the aforementioned exception kicks in, and
customize politely preserves the value set by the
defvar, thereby ignoring your customization.
You can verify that this is the issue by adding
(defvar tramp-remote-path nil)
.emacs, before the actual call to
custom-set-variables. That should fix it (because now
custom-set-variable will think the variable exists), but I don't know enough about
customize to recommend this solution.