Last day to vote/reject on proposed EOL names

[Talden]

>> eol = native (99.9% of text content)
>
> Yes, this is closer to what I'd expect - although I was expecting a few more
> 9s on the end ;)

And the real numbers of the overall project are...
exact  == 28.976%
native == 70.433%
LF     ==  0.04%
CRLF   ==  0.551%

I expect that as much as half of those marked as exact should actually
be native.

Don't let those small numbers fool you though, CRLF and LF are still
critical to us and we'd have to build some sort of pre-processing into
our build if the VCS wasn't doing this for us.

>> eol = crlf (a small number of files)
>> eol = lf (a small number of files)
>
> I'm genuinely interested to know what practical problem is being solved by
> these extra files.  I can think of a number of 'purity' arguments why they
> might appear desirable, but still having trouble coming up with a *real*
> problem, in practice, caused by not having these modes.  I'd like to be
> enlightened so I can concede my ignorance :)

Some brain-dead windows-only applications that do not recognise lf as
a line-separator and linux shell scripts that don't work if they have
crlf.  There are others.

In both cases the files may be checked out on either platform to build
an installer that includes these files. That installer can then be run
on either platform but needs it's install content to be correct.

In addition, just having the files with uniform EOLs can make life
easier in some circumstances.

--
Talden