Line ending translation extension

["Martin v. Löwis"]

>  > I'm not sure what you want me to cut out exactly;
> 
> The repeated "don't blame Windows."  It *is* a problem for Windows but
> *not* for Unix. 

I think this is the formulation that sets Mark up. Maybe it is a
problem "on" Windows, but not "for" Windows. If it was a problem
for Windows, whose job would it be to solve it? Windows? Microsoft?
Mark Hammond?

It's a problem for Python.

>  > I agree it is tedious to hear me continue to point out that this
>  > isn't an imagined problem, but I'm simply responding to what is
>  > continually asserted.
> 
> What I see asserted is quite different: that (a) they don't experience
> it themselves, and (b) that they don't understand how a problem can
> arise frequently enough to worry about it.  Some of those people
> develop primarily for and with Windows!

However, it's puzzling that people repeat these assertions, despite
having seen explanations for why it happens.

> This is important to the design.  AIUI, Martin v. Löwis is saying
> "right, it's pretty rare, but *extremely* annoying when it does
> happen

No - I don't think I said it's pretty rare (at least, I didn't mean
to). New files being added with the wrong line endings is fairly
common - about every addition made to Python on Windows had the problem.
Every committer did that several times, both with CVS and with
Subversion. With Subversion, people are now expected to configure
their local installation to fill out the [auto-props] section
properly (the proposed extension would solve this in a better way
than subversion). Tim Peters wrote a script to fix that precisely
to automate the work-around (of redoing commits in the right
eol-style).

What is considerably less frequent is editors which add CRLF
line endings to existing LF files. I'm fairly sure that for
some time, the VS editor would do that. Not sure whether Microsoft
has fixed that; as now all interesting files are CRLF on Windows
(using svn:eol-style), the problem is not that observable (with
subversion - for a Mercurial installation without extension,
I'm sure it would show up again).

> so let's do something 100% simple and 99% usable to cut that
> down to 'almost never'."  And that's probably good enough IMO.  OTOH,
> you are evidently more concerned about it, and give the impression
> that you think it's a harder problem, as well.  If "harder problem"
> turns out to be the case, a deeper/more complex solution may be
> warranted.

What he is concerned about is that he may have to maintain the
extension if he just barely touches it. I can understand that.
The hard problem is a social one, not a technical.

The technical problem primarily comes from ad-hoc solutions, such
as win32text. This tries to eliminate the need for configuration,
by applying magic - not recognizing that the problem is so serious
that it requires manual configuration (which then needs to be
in the repository, to be usable).

> Method A: Text files are labeled according to target platform
> convention: LF, CRLF, or native.  LF and CRLF are checked out as
> binary, checked for the proper conventions on check in, and converted
> as necessary.  This would give some additional flexibility, and better
> checking, but it's more complex.  Visual Studio project files would be
> labeled as *CRLF*.  This seems the leading candidate.
> 
> Method B: Text files are always decoded and reencoded according to
> user preference, defaulting to platform convention.  Visual Studio
> project files would be classed as *binary*.  This is simpler and
> flexible but allows less fine-grained checks..

In this method, how do you know what a text file is?

I think this is a description of win32text, and it doesn't work.
Method C has the same flaw, AFAICT.

Regards,
Martin