win32text and excluding patterns

[Mads Kiilerich]

Mark Hammond wrote, On 04/10/2009 06:16 AM:
> 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.
>    

I think it "works as designed": The "!" notation is only for disabling 
all filtering for _a_specific_ pattern - and it works because there can 
only be one filter specification for each pattern. I think ordering _is_ 
preserved for the filters, but while an early "!" disables that pattern 
it doesn't stop the filter engine from continuing with the next filter 
and match and apply that.

What you ask for could be a nice feature, but it isn't obvious to me how 
it would fit what currently is implemented. And note that a patch must 
preserve the current behavior.

Take a look at mercurial.localrepo.localrepository._filter

Hmm. Perhaps you can do something close to what you ask for with 
something like:

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

But the simplest solution would perhaps be to create an extension with 
your own custom "smarterencode" which does exactly what you want.

/Mads

ps: Yes, visual studios parser implementation - and file format in 
general - for dsp and dsw files is crazy.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3435 bytes
Desc: S/MIME Cryptographic Signature
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20090414/e217e171/attachment.bin