emacs-devel
[Top][All Lists]
Advanced

[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 20:22:30 +0300

> From: address@hidden (Kai =?iso-8859-1?q?Gro=DFjohann?=)
> Date: Sun, 05 Aug 2001 18:48:33 +0200
> 
> "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.

I might be missing something, but aren't you contradicting yourself?
First you say that it is wrong to require that file-name patterns
overlap, then you say that it works well except with Tramp.  The first
utterance suggests that the current approach is wrong, the second one
says that it is right.  No?

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

The alternative I suggested frees you from being aware of the order in
which the handlers install themselves.  Moreover, it's quite possible
that some other package installs a handler _after_ your handler is
already installed (and thus takes precedence), in which case you don't
get a chance of doing anything about that, because your handler isn't
called when the other one installs itself.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]