Re: file-relative-name and remote files

[Kai Großjohann]

Lars Hansen <address@hidden> 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.