Re: Tramp, "[]" in file names, and file-expand-wildcards

[Stefan Monnier]

> > From: address@hidden (Kai =?iso-8859-1?q?Gro=DFjohann?=)
> > Date: Tue, 09 Oct 2001 12:08:11 +0200
> > > 
> > > Aren't there situations where the order of the handlers' invocation is
> > > important?
> > 
> > Hm, yes, quite possibly.  So, should the filename handlers be
> > rewritten so that order does not matter?
> 
> It would be one possibility, but I don't see how can you reasonably
> require a handler to behave like that.

I once tried to get ange-ftp and jka-compr to work both ways (right now,
it only works if jka-compr is activated after ange-ftp, which is always
the case since ange-ftp is pre-activated) and the problem basically boiled
down to making ange-ftp download /host:dir/file1.gz into /tmp/file1.gz
(or even /tmp/file2.gz) rather than /tmp/file2.

Now if we had a tar-file handler, there simply wouldn't be any way for
ange-ftp to correctly handle /host:dir/file.tar/member without
embedding a lot of knowledge about this tar-file handler in ange-ftp's
code.  I.e. the only real solution is to make sure that tar-file
handler is registered after ange-ftp.

For this reason, I agree with Eli and think it's not just unreasonable
but impossible in general.

> Another possibility would be to invent a mechanism where each handler
> could register a priority, and higher-priority handlers would be
> called first.  That would allow a handler to DTRT no matter what is
> the order of loading the respective packages into Emacs.

I think it's the good and simple approach.

But based on the little bit of experience we have with various kinds of
handlers, it seems that the priority should reflect where the pattern matches
(things like jka-compr that match the very end should have the highest
priority, then come tar-file handlers and then ange-ftp like thingies).
The interesting thing to note is that if we have a zip-file handler
and a tar-file handler, the order in which they should be applied
depends on the file name.  For /foo.tar/bar.zip/baz, we first want to
apply the zip handler, whereas for /foo.zip/bar.tar/baz, the opposite
holds.  So maybe the function applies the patterns in turn should
be changed to choose not "the first that matches" but "the one whose
(match-end 0) is largest".

> > The whole thing is a thorny subject, I guess.  I guess a high-level
> > design decision is necessary, first, before trying to hack the
> > individual packages to work around this.
> 
> If people agree that the order of invocation matters in enough cases,
> then there should be a high-level design decision.  Otherwise, we can
> go on kludgeing around this ;-)

The more I think about it the more I'm convinced that
"the largest (match-end 0)" is The Right Thing.


        Stefan