Re: copy-file with two remote files behaves strangely

[Kai Großjohann]

"Eli Zaretskii" <address@hidden> writes:

>> 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.

The copy-file problem is the only problem with overlapping patterns
that I've found so far.  For all the rest, Emacs takes the first
matching entry in file-name-handler-alist, and that works nicely.  At
least with Tramp and ange-ftp.

There are so many places in Emacs where an alist is traversed in
order, then the first matching entry is taken -- why should
file-name-handler-alist be different?

> 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).

This is already the case now: the ordering in file-name-handler-alist
matters.

But I guess the point is that different handlers might need to be
aware of each other, so that they can be installed in the right order.

>> 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?

Oh.  Maybe my message was a bit unclear.  Just getting tar to work is
not the problem.  I think problems begin when several filename
handlers apply to the same file.  Then the correct processing might
depend on the order in which the handlers are invoked.  (Though who
can tell for sure, it's not been done yet.)

Hm.  Maybe I should try whether a gzipped file via ange-ftp works with
jka-compr before ange-ftp in file-name-handler-alist as well as vice
versa.

kai
-- 
~/.signature: No such file or directory