From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.devel Subject: Re: file-relative-name and remote files Date: Wed, 12 Mar 2003 12:53:15 +0100 Organization: University of Duisburg, Germany Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <844r68hkd0.fsf@lucy.is.informatik.uni-duisburg.de> References: <3E6EDFAA.4080500@math.ku.dk> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1047472195 30487 80.91.224.249 (12 Mar 2003 12:29:55 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 12 Mar 2003 12:29:55 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Mar 12 13:29:54 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18t5Mo-0007vZ-00 for ; Wed, 12 Mar 2003 13:29:54 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18t5k2-0005ad-00 for ; Wed, 12 Mar 2003 13:53:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18t5Mr-0007ly-0A for emacs-devel@quimby.gnus.org; Wed, 12 Mar 2003 07:29:57 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18t5K4-0006D5-00 for emacs-devel@gnu.org; Wed, 12 Mar 2003 07:27:04 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18t5BY-0003GX-00 for emacs-devel@gnu.org; Wed, 12 Mar 2003 07:18:17 -0500 Original-Received: from main.gmane.org ([80.91.224.249]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18t4ne-0008FL-00 for emacs-devel@gnu.org; Wed, 12 Mar 2003 06:53:34 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18t4mv-0005jP-00 for ; Wed, 12 Mar 2003 12:52:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18t4mt-0005j5-00 for ; Wed, 12 Mar 2003 12:52:47 +0100 Original-Lines: 59 Original-X-Complaints-To: usenet@main.gmane.org User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:5t+eet9uegS4KikY0WTSN/XbEYk= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:12302 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12302 Lars Hansen writes: >>I think it is not a good idea to change the filename syntax in such a >>way, for that would mean that people can't use filenames with colons >>in them anymore. That would be too drastic, I think. >> >>Our BibTeX citation keys are of the form Smith:95, and we store the >>corresponding fulltext documents in files named after the citation >>key. >> > Clearly colons in names of files in directories other than root should > be allowed. Tramp should not barf, it should just call the normal > handler. Would that not work? Hm. Let's see. Here is what could be done: * The regexp in file-name-handler-alist is not anchored with ^. * Every Tramp handler does a second check to see if the match is actually at the start of the file. If so, it does its thing. If not, it invokes the normal operation. * The expand-file-name operation gets special treatment: there, Tramp splits the filename into two parts, the pre-match part and the post-match part. (For a filename "/a/../foo:/bar", the pre-match part would be "/a/.." and the post-match part would be "/foo:/bar".) It then invokes the normal operation on the pre-match part. If that results in "/" (or the equivalent of "/" on a Windows system), then it does what it does now on the post-match part. If the normal operation returned something different from "/", then the result is the result of the normal operation on the full string. I think this might achieve the objective. It is, however, a rather complicated algorithm. Also, this burden is on every file handler. Note that every operation needs to do the additional "did it match at the beginning" check! The alternative would be to change expand-file-name as I suggested: if there was no handler, do your thing and then look if there is another handler to invoke, and if so, then invoke it. Apart from the implementation considerations, there is also the conceptual level: IMHO, the ..-leads-to-different-handler problem is a general problem that does not depend on any specific handler. So this general problem should be handled in the general code, rather than requiring every handler to deal with this case. (However, I am a bit sceptical about arguments on the conceptual level: I failed to convince people with a similar, conceptual, argument regarding copy-file. (copy-file has problem that several handlers might be involved as the two files might come from different handlers. I suggested to add code in copy-file to deal with this issue, but I think I didn't convince anyone that this is a good idea. Maybe if I'm successful with the expand-file-name issue, I will bring up the copy-files issue another time :-) -- A preposition is not a good thing to end a sentence with.