"Konstantin Ignatiev" <[EMAIL PROTECTED]> 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 "/[EMAIL PROTECTED]:path" into something very ugly like > "c:/[EMAIL PROTECTED]: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. _______________________________________________ Tramp-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/tramp-devel
