[MERGE] integrated EOL conversion support

[Alexander Belchenko]

Ian Clatworthy пишет:
> Alexander Belchenko wrote:
>> Ian Clatworthy пишет:
> 
>>> Thinking out loud, I wonder whether "windows" would be a better
>>> choice than "dos"? I'm probably showing my age by using the latter.
>> I'd prefer 'CRLF' and 'LF' instead of 'dos' and 'unix'.
> 
> Based on your suggestion and mailing list feedback, I've gone with
> 'lf' and 'crlf' in the attached patch. (I prefer lower-case values as
> they are softer on the eyes.)
> 
> I've also expanded the documentation with more information and more
> examples, and included explicit tests for binary file handling.

John has explained reason for crlf/crlf case and now I think I'm finally understand
your filter logic.

Ian, I'm very high appreciate your work, and I really think that your patch
is better than nothing at all.

But I should say that your defaults does not satisfy my needs.

+_eol_filter_stack_map = {
+    'exact': [],
+    'lf':    [filters.ContentFilter(_to_lf_converter, _native_output)],
+    'crlf':  [filters.ContentFilter(_to_crlf_converter, _native_output)],
+    }

I need the way to force lf on windows. How can I achieve this?

Can we add to the stack map above more variants, please? I'm thinking about
specify pair of converters with slash, e.g.:

	'lf/lf': [filters.ContentFilter(_to_lf_converter, _to_lf_converter)],
	'crlf/lf': [filters.ContentFilter(_to_crlf_converter, _to_lf_converter)],
	'lf/crlf': [filters.ContentFilter(_to_lf_converter, _to_crlf_converter)],
	'crlf/crlf': [filters.ContentFilter(_to_crlf_converter, _to_crlf_converter)],

This way people will have power to specify any variants they ever need!

Of course many people will use simple 'lf' and 'crlf' rules, but for some weird cases
there always will be another variants. You can describe them separately as advanced
option somewhere in the end or as see also document.

Please. Please! Please?

> Can you re-run the latest tests please?

Sure, will do

> 
>>> I'm also considering adding a value called "clean". That would work
>>> exactly like "exact" except it would warn if mixed line-endings
>>> were found in a file. What do you think? Git has something like this
>>> so I gather it's of value to users.
> 
> I've explained in a separate email why I think, after further reflection,
> "eol = clean" is the wrong approach. We should make it easy to check that
> certain files meet certain rules but that's best done outside the eol
> conversion filter IMO.
> 
>> I think it makes sense. Especially when people want to clean their hairy files.
> 
> Maybe "eol = auto" can clean files by detecting the right convention,
> from the first line say. Anyhow, it's a frill that can come in a later
> patch.
> 
> Ian C.
>