win32text and excluding patterns

[Mads Kiilerich]

Mark Hammond wrote, On 04/14/2009 11:33 PM:
>> 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>
>    

It _could_ be a generic extension. And if don't want the Mercurial 
encode/decode semantics then you must (re)implement your own semantics 
somehow anyway.

I don't think you can get the filtering you want in/with core Mercurial, 
so an obvious solution is to do it with an extension.

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

Perhaps. But pragmatically: either you notice and can fix it, or you 
don't notice and then it doesn't matter ;-)

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

Right, right now people can't rely on the ordering. But people rely on 
** filters being applied to _all_ files. What you are asking for is 
exceptions to that, right? It is hard to get both. (But again, it 
_could_ be done if the ** filter was applied first to all files, and a 
**.ds* filter came next and un-did these changes. Uff. That is ugly.)

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

I think you should ask the core/crew developers instead ;-)

But yes, I encourage you ... to do it in an extension where you have the 
freedom to do exactly what you want, without being limited by the 
current implementation and backwards compatibility.

A limitation (or feature, depending on POW) is that filter definitions 
doesn't follow repo clones but most be done in each clone individually.

I could imagine that it could be convenient to specify filtering in for 
example a simple versioned .hgfilter. The only change to do for each 
clone would be to enable the extension that recognizes this file - and 
that extension could be enabled globally. These filters would have to be 
less powerful and flexible than the existing filter commands - otherwise 
it would be a security risk. The next thing you will need for win32 
could be transcoding between utf-8 and utf-16 and windows codepages as 
well as handling of BOMs, and that could benefit from this kind of 
filter specification too. MPM do however not like that kind of meta 
data, so it will probably not get into core Mercurial.

/Mads


-------------- 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/20090415/4ea40d29/attachment.bin