[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,
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
so.
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
welcome!
> Thank you!
> ::Konstantin::
Best regards, Michael.