win32text and excluding patterns

[Mark Hammond]

> > I'm not trying to nitpick, but 'disabling a previously defined rule'
> > is quite a bit different to the user than 'disabling filtering for a
> > pattern' - I'm after a way of disabling *all* filtering for a
> > specific
> > pattern.
> 
> Yes. That could be nice, but that is not what ! is for. The current
> description might be misleading - how could the documentation be
> improved?

Actually I couldn't find *any* docs for the '!' behaviour - I deduced it by
looking at the sources after a pointer from IRC.

By my suggestion would be that whereever this *is* documented, its not
advertised as "disabling filtering for a pattern", but simply a way of
disabling a rule for the same pattern that appears in a different config
file.

> Ok, right, I wasn't sufficiently exact. The ordering of the patterns on
> left hand sides is not preserved, but ConfigParser reads the config
> lines in order, and the last specification for each left hand side
> pattern thus wins.

To be clear: are you simply saying that values from the last config file
read will override any read in earlier ones, or something different?

> MPM is usually very focussed on preserving existing functionality, so
> unless it is an obvious bug then I think the documentation should be
> improved.

Thanks for the explanations - I now see that trying to use '!' for my
requirement doesn't fit how '!' works - thanks!

> My idea was to bypass Mercurials pattern functionality and apply
> "smarterencode" to _all_ files. Smarterencode could then implement your
> heuristics by looking at the file name, extension and content.

I really don't like that idea - it would mean basically reimplementing the
entire '_filter()' function in my extension point.  That is quite a burden
for someone who just wants sane line-endings on windows <wink>

> > I think I must be missing something though, as the current behaviour
> > doesn't really seem useful for people using Windows all day.
> 
> Yes, I think you are right about that. Sorry.
> 
> Perhaps you could apply cleverencoding to specific patterns only - such
> as **.c, **.h, **.txt.

Yes, that would work, but is still too error prone for what I want to do.  I
*will* forget some extensions commonly used.

I'm now really hoping we can reach agreement on an 'implied ordering' for
the filters themselves.  I also hope this will not hit the backwards
compatibility issue in the same way - as the current order can't be
determined, people can't be relying on it.

Do you have any thoughts (hopefully of encouragement :) for that idea?

Thanks,

Mark