Re: copy-file with two remote files behaves strangely

[Eli Zaretskii]

> From: address@hidden (Kai =?iso-8859-1?q?Gro=DFjohann?=)
> Date: Sun, 05 Aug 2001 13:43:22 +0200
> 
> I don't think that requiring filename patterns to be nonoverlapping
> is the right approach, anyway.

However, note that the current file-name-handler machinery is
_entirely_ based on this assumption.  Namely, the lookup for a handler
is based on regexp matching against the file's name, and thus
overlapping file-name patterns is generally a bad idea.  That is, you
are suggesting a significant change in how this feature works until
now.

In addition to the possibilities you mentioned, I can see another one:
allow each file-name handler define a `priority' indication.  This
way, certain handler could install themselves such that they will take
precedence (find-file-name-handler will have to be changed to find the
highest-priority handler instead of the first one).

> Hm.  The above description is nice as far as it goes, but it probably
> does not deal well with the really tricky cases.  In fact, I'm
> thinking of writing a filename handler for tar files, so that you can
> say C-x C-f /tmp/foo.tar/README RET to open the file README contained
> in the tarball /tmp/foo.tar.  (I know of the package tar-mode.el,
> which does not quite do this.)  I think it would be useful to design a
> solution which can deal with this case.

Why cannot this case be handled by the existing file-name handler
infrastructure?  Aren't you going to depend on the fact that an
archive has a name with `.tar' extension?