[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: copy-file with two remote files behaves strangely
From: |
Eli Zaretskii |
Subject: |
Re: copy-file with two remote files behaves strangely |
Date: |
Sun, 05 Aug 2001 18:29:14 +0300 |
> 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?