From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Newsgroups: gmane.emacs.tramp,gmane.emacs.devel Subject: Re: Tramp and file-name-handler-alist Date: Thu, 24 Oct 2002 11:20:30 +0200 Sender: tramp-devel-admin@nongnu.org Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035451258 13122 80.91.224.249 (24 Oct 2002 09:20:58 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 24 Oct 2002 09:20:58 +0000 (UTC) Cc: emacs-devel@gnu.org, Tramp Developers Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 184eAj-0003PW-00 for ; Thu, 24 Oct 2002 11:20:57 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 184eCp-00007J-00 for ; Thu, 24 Oct 2002 11:23:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 184eBC-00038l-00; Thu, 24 Oct 2002 05:21:26 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 184eAO-00023t-00 for tramp-devel@mail.freesoftware.fsf.org; Thu, 24 Oct 2002 05:20:36 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 184eAL-00023Y-00 for tramp-devel@mail.freesoftware.fsf.org; Thu, 24 Oct 2002 05:20:35 -0400 Original-Received: from mx2.informatik.uni-tuebingen.de ([134.2.12.9]) by monty-python.gnu.org with esmtp (Exim 4.10) id 184eAL-00023O-00 for tramp-devel@mail.freesoftware.fsf.org; Thu, 24 Oct 2002 05:20:33 -0400 Original-Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx2.informatik.uni-tuebingen.de (Postfix) with ESMTP id 4D9E11066; Thu, 24 Oct 2002 11:20:30 +0200 (MST) Original-Received: from sams.informatik.uni-tuebingen.de (localhost [127.0.0.1]) by sams.informatik.uni-tuebingen.de (8.12.3/8.12.3) with ESMTP id g9O9KUil046138; Thu, 24 Oct 2002 11:20:30 +0200 (CEST) (envelope-from sperber@sams.informatik.uni-tuebingen.de) Original-Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.12.3/8.12.3/Submit) id g9O9KUWn046137; Thu, 24 Oct 2002 11:20:30 +0200 (CEST) Original-To: Michael Albinus In-Reply-To: (Michael Albinus's message of "09 Oct 2002 14:34:14 +0200") Original-Lines: 42 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.5 (brussels sprouts, i386-unknown-freebsd4.6.2) Errors-To: tramp-devel-admin@nongnu.org X-BeenThere: tramp-devel@nongnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.tramp:861 gmane.emacs.devel:8725 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8725 >>>>> "Michael" == Michael Albinus 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