Tramp and file-name-handler-alist

Tramp and file-name-handler-alist

[Michael Albinus]

Hello,

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.

Re: Tramp and file-name-handler-alist

[Michael Sperber [Mr. Preprocessor]]

>>>>> "Michael" == Michael Albinus <Michael.Albinus@alcatel.de> writes:

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

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

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

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

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

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

I've always argued for putting a meta-mechanism on top of
Tramp/EFS/ange-ftp, which would have a compositional way of specifying
how file-name handlers are assembled, and which includes a way of
using predicates in the manner described.

I do think that distinguishing remote file names from local ones
syntactically is a good thing, but once that distinction is made (and
it can be made in `file-name-handler-alist'), we'd be home-free.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Re: Tramp and file-name-handler-alist

[Michael Albinus]

sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr.  Preprocessor]) writes:

> I've always argued for putting a meta-mechanism on top of
> Tramp/EFS/ange-ftp, which would have a compositional way of specifying
> how file-name handlers are assembled, and which includes a way of
> using predicates in the manner described.

In fact the latest changes in Tramp go this way. All code integrating
ange-ftp has been moved to tramp-ftp.el. Once tramp-file-name-handler
has been chosen by find-file-name-handler, it calls
tramp-ftp-file-name-p in order to find out whether ange-ftp has to be
used, and hands over control in case of.

By this, the tight folding of ange-ftp into Tramp has been reduced to
a small interface, which could be applied for EFS as well.

A more general approach would take something similar to
file-name-handler-alist for Tramp internal use as well. Instead of
declaring a regexp for decision, there might be a function (with
filename as parameter). Something like this:

((tramp-ftp-file-name-p . tramp-ftp-file-name-handler)
 (tramp-smb-file-name-p . tramp-smb-file-name-handler))

At the beginning of tramp-file-name-handler this list is parsed, and
the respective handler is called. tramp-ftp-file-name-handler would be
a wrapping function, which calls either ange-ftp-hook-function or 
efs-file-handler-function. tramp-smb-file-name-handler is under
development for accessing SMB servers (SAMBA, or M$ operating systems).

Best regards, Michael.

PS: I guess we can shorten the distribution list of this thread to
    tramp-devel. The major issues of integrating into Emacs seem to be
    clear.