win32text and excluding patterns

Mark Hammond skippy.hammond at gmail.com
Thu Apr 9 23:16:27 CDT 2009


Hi all,
   I'm trying to get the win32text extension to ignore certain patterns 
and I'm having trouble.  What I want is something like the following:

   [encode]
   **.dsp = !
   **.dsw = !
   ** = cleverencode:

IOW, all files _except_ *.dsp and *.dsw should use clever encoding. 
I've dug around the mailing lists and the sources and it seems some 
attempt is indeed made to handle '!' - and it seems to have been 
introduced with a similar motivation:

http://markmail.org/message/g55ev2ka7yseaept

But best I can tell, it's not working in my case as the '**' still 
matches.  IOW, using '**=!' is useful - it temporarily disables all 
encodings - but it's not useful for any other extension when a '**' is 
in force.  Am I misunderstanding something?

So I thought maybe a way forward was to define new "pass-through" 
encoders called, eg, 'exact' - they just return exactly what was passed 
to them.  Then I could do something like:

   [encode]
   **.dsp = exact:
   **.dsw = exact:
   ** = cleverencode:

But this falls over for a similar reason; ordering in the sections is 
not maintained, so the '**' may still match first.

An easy solution that avoids trying to capture "full" ordering might be 
to have the code classify the filters into 3 categories - those without 
a wildcard, those with a wildcard, and '**'/'*', and ensure the filters 
are applied in that order.

The handling of '!' still seems suspect to me though - it acts more like 
"pretend this filter line doesn't exist" than the expected "record that 
this extension explicitly wants no filtering".  Am I missing the intent 
of '!' (and therefore my idea of a new 'exact' encoding makes sense), or 
is the implementation of '!' suboptimal, meaning I could implement my 
requirements by changing the handling of '!'?

I'm happy to make a patch for this, but thought I'd check here first 
that I'm not missing anything obvious and what the best way forward is.

Thanks,

Mark


More information about the Mercurial-devel mailing list