Last day to vote/reject on proposed EOL names

[Eric Siegerman]

Ian, thanks for giving the two-property proposal serious
consideration, even though it didn't win out in the end.


Re. the revised (single-property) documentation:

It could say more about binary files.  The only mentions I can
see are (a) the null-character override, and (b) the mention that
"exact" != binary.  That raises two questions:
  - What's the difference between exact and binary?

  - Since specifying "eol=exact" doesn't say that the file is
    binary, how *does* one do the latter?  Is there a way,
    short of making sure that no explicit eol rule matches the
    file?


> Note: For safety reasons, no conversion is applied to any file where a
null
> character is detected in the file.

Does this mean null Unicode characters or null bytes?  (Maybe
this is my Java bias talking, that "character" implies 16-bit.
Is the same true in the Python world?  Still, it would be useful
to clarify.)

> Here is the suggested rule for users working on a cross-platform
project:
> 
>   [name *]
>   eol = native

This would appear to apply "native" conversion to binary files
that don't happen to contain any null (chars|bytes), and don't
happen to be matched by higher-precedence rules.  Is that in fact
the case?  If so, that should probably be at least mentioned; if
not, why not?



On a different note, this bit:
> For developers working on a project using Windows newline conventions
as
> the project standard, this rule is suggested:
> 
>   [name *]
>   eol = native-with-crlf-in-repo

disagrees with this bit:
> If you have an existing repository with text files already stored
using
> Windows newline conventions (crlf) [...]

as to when to use "*-with-crlf-in-repo" options.  One of them
needs to be changed.  (IMHO, it's the first one that should
change -- I agree with Alexander's earlier comments that those
options should really only be used for legacy CRLF-containing
repos, not for new repos even if Windows-based.)

  - Eric