[Top][All Lists]

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

Re: Tramp and file-name-handler-alist

From: Michael Sperber [Mr. Preprocessor]
Subject: Re: Tramp and file-name-handler-alist
Date: Thu, 24 Oct 2002 11:20:30 +0200
User-agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.5 (brussels sprouts, i386-unknown-freebsd4.6.2)

>>>>> "Michael" == Michael Albinus <address@hidden> 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

reply via email to

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