[Top][All Lists]

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

Tramp and file-name-handler-alist

From: Michael Albinus
Subject: Tramp and file-name-handler-alist
Date: 09 Oct 2002 14:34:14 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7


Tramp uses its own file name syntax for getting control over file
i/o primitives, using a regexp in file-name-handler-alist.
Unfortunately this has the disadvantage, that Tramp must handle all
file names with that syntax, even if it isn't responsible for them
(like Ange-FTP related files). And more Tramp methods might appear,
which won't be handled directly by Tramp but external modules.

Distinguishing Tramp file names by syntactical means, depending on
method name, doesn't work because Tramp applies a default method if
none is given.

So it would be desirable to have a more general possibility deciding a
file-name-handler. Perfect would be an extension to
file-name-handler-alist, which doesn't allow a regexp only but also a
function for decision. Something like

   ; forward to Ange-FTP or EFS
 ((tramp-ftp-file-name-p . tramp-ftp-file-name-handler)
   ; the rest of the pack
  (tramp-file-name-p . tramp-file-name-handler)
  ("\\`/:" . file-name-non-special))

For backward compatibility reasons, this wouldn't be a short term
solution. With the current interface, I see 2 possible approaches:

- Do it within tramp-file-name-handler. The filename is analyzed, and
  then the respective handler for a method is launched. This handler
  calls the respective primitive functions related to the method.
  The disadvantage is, that tramp-file-name-handler is called with
  different paramter lists for the primitives, and sometimes even the
  filename isn't part of.

- Replace find-file-name-handler by an own implementation. In case of
  Tramp file names it returns the handler related to actual method,
  otherwise it calls the original find-file-name-handler.

Are there other possibilities to solve the problem? And which approach
is to prefer?

Best regards, Michael.

reply via email to

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