[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs unconditionally loads tramp.el

From: Eli Zaretskii
Subject: Re: Emacs unconditionally loads tramp.el
Date: Sun, 30 Apr 2006 20:46:39 +0300

> From: Oscar Fuentes <address@hidden>
> Date: Sun, 30 Apr 2006 15:03:24 +0200
> Jason Rumney <address@hidden> writes:
> > Oscar Fuentes <address@hidden> writes:
> >
> >> (setq tramp-default-method "plink")
> >>
> >> and you are done.
> >
> > That is the default if plink is in your path. See the definition of
> > tramp-default-method.
> I see no reference to PATH on that variable's help:

That's because the variable itself indeed does not have _any_ relation
to PATH whatsoever.  It's the way we set the _default_value_ of the
variable that looks along the PATH:

    (defcustom tramp-default-method
      (if (and (fboundp 'executable-find)
               (executable-find "plink"))

>From the end-user's point of view, it is not important how Emacs
figured out it should use plink, whether by searching PATH or some
other magic.  As long as the default makes sense, the user should be
happy, since the related features will ``just work''.

So I don't think the doc string should mention PATH in this case.

(Note that Jason suggested that you look at the _definition_ of
tramp-default-method, reproduced above, not at its _doc_string_.)

> And now that we are at it, copying archives is broken (with dired
> buffer showing the remote files, using `C' over a binary file, copy to
> local system. Remote is NetBSD, local is WindowsXP, the file copied to
> local machine has lots of bytes inserted here and there. It seems not
> a line-end conversion problem). Assigning pscp (PuTTY's copy program)
> to tramp-copy-program makes no difference: Tramp keeps
> uuencoding-uudecoding the file.

Sorry, it's impossible to debug the problem using this description.
Could you please provide a short self-contained test case that can be
used to reproduce the bug?

> Furthermore, Tramp seems to have problems detecting the coding system
> of a remote file: loading a remote file with accented chars and saving
> it again, converts the accented chars to something else, without
> notice.

Again, please provide a specific recipe (in particular, what non-ASCII
characters were in the file and how were they encoded).


P.S. Please use a different Subject when you post the details of those
two problems, preferably as two separate messages.  TIA

reply via email to

[Prev in Thread] Current Thread [Next in Thread]