[Top][All Lists]

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

Tramp is broken in Emacs 22.1 on Windows

From: Konstantin Ignatiev
Subject: Tramp is broken in Emacs 22.1 on Windows
Date: Thu, 1 Nov 2007 10:07:50 -0400


I have been using TRAMP for at least a few years, usually with
beta-versions of Emacs 22, and on occasion even with Emacs 21.3 (not
without problems, though), and mostly on Windows. It has been very

Now as there is finally Emacs 22.1 release available, I began using
that, and unfortunately it appears TRAMP is seriously broken.

I believe there are two problems (I only tried TRAMP 2.0.55
distributed with Emacs 22.1, and only under Windows XP).

First and the most serious problem is in fact Windows-specific. TRAMP
top-level handler for files tramp-file-name-handler has this logic

    ;; When we are in completion mode, some operations shouldn't be
    ;; handled by backend.
    ((and completion (memq operation '(expand-file-name)))
     (tramp-run-real-handler operation args))
    ((and completion (zerop (length localname))
          (memq operation '(file-exists-p file-directory-p)))

So if I pass operation=' expand-file-name, it will simply call
"default" (="real") handler as if this were local file system name.
Under UNIX, this is probably harmless, but under Windows it turns
TRAMP names like "/address@hidden:path" into something very ugly like
"c:/address@hidden:path". These are the rules how (local) file names are
"expanded" on Windows.

This can potentially lead to many problems later on, but the one most
visible and most annoying is that file completion in TRAMP no longer
works (I guess this is because before "completing" name we try to
"expand" it)

Second problem is how file-completion works in Emacs 22.1 / TRAMP
2.0.55. The aforementioned  tramp-file-name-handler is called with
operation='file-name-completion and THREE arguments: file name,
directory name, and filter; no "filter" used to be passed down in the
older versions I had been using before. In this case, filter is merely
file-exists-p . The way this is implemented in tramp.el, we therefore
test EACH possible completion for existence, each time asking the
remote server. This could be VERY slow even on a good network, if
remote machine isn't very fast or loaded.

I experienced this problem on Windows, though I don't see how this
possibly could be platform-dependent (unless generic file completion
framework is).

And, one more remark unrelated to these specific issues. Current TRAMP
documentation makes it look like Unix-only tool; (native) Windows
platform is barely mentioned at all. This is sad, since TRAMP can be
easily configured to work on Windows using freely available "plink"
(part of PuTTy distribution). I think this should be mentioned in the

Thank you!

reply via email to

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