[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