[Top][All Lists]

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

Re: Tramp is broken in Emacs 22.1 on Windows

From: Michael Albinus
Subject: Re: Tramp is broken in Emacs 22.1 on Windows
Date: Sat, 03 Nov 2007 16:03:45 +0100
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.50 (gnu/linux)

"Konstantin Ignatiev" <address@hidden> writes:

> Hi,


> First and the most serious problem is in fact Windows-specific. TRAMP
> top-level handler for files tramp-file-name-handler has this logic
> built-in:
>     ;; 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)))
>      t)
> 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)

There have been related changes in Tramp 2.0 since the release of Emacs
22.1. Could you, please, check with Emacs CVS (branch EMACS_22_BASE) or
Tramp CVS (branch branch-2-0-stable), whether your problem is solved? I
would guess it. These changes will be available with Emacs 22.2.

> 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.

What shall Tramp do else? If `file-name-completion' is called with a
predicate, `tramp-handle-file-name-completion' is supposed to apply this
predicate. Yes, this might be a performance problem.

But: in Tramp 2.1, there is a lot of caching. A call of `file-exists-p'
for the same file will result only the first time in a remote
command. Afterwards, the cached result is used for consecutive calls.

> 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
> doc.

You're right, plink could be mentioned in the Overview chapter. I'll do

However, Tramp IS developped by people who don't use Win32 systems
regularly. This is visible in the documentation. I would appreciate if
somebody with that background could participate; you are really really

> Thank you!
>  ::Konstantin::

Best regards, Michael.

reply via email to

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