EOL extension and patch.eol

[Mads Kiilerich]

Martin Geisler wrote, On 12/07/2009 12:53 PM:
> Side comment: After speaking with Mads Kiilerich yesterday, I realized
> that the encode/decode filter mechanism is broken: it only allows you to
> specify one filter for a given file. So the eol extension would prevent
> other filters from being used.
>
> But perhaps this isn't a big problem -- I think the win32text extension
> is the only thing that uses the filters so far.
>
> The documentation gives a fun example of how one can use gzip/gunzip to
> get better delta-compression (and nice diffs) by storing .gz files
> uncompressed in the repository. But it also says that this is perhaps
> not a good example.

Christian Ebert, you are Mr. keyword extension. I notice that the 
keyword extension doesn't use Mercurials encode/decode filter mechanism. 
Can you say something about why? Can you point out some shortcomings of 
the filter mechanism which perhaps also can explain some bad experiences 
with win32text?

It also seems to me like most the keyword extension is monkey-patching 
for introducing another filter mechanism. Do you think that is something 
that other kinds of content filtering could utilize and benefit from too?

(With reference to 
http://mercurial.selenic.com/wiki/EOLTranslationPlan#Content_filtering_hooks 
)

/Mads