[RFC] eol values: unix/windows or LF/CRLF?

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Yes.  If you want it to be short, I think we (Emacs maintainers)
 > concluded that "/" for LF, "\" for CRLF and ":" for CR was a pretty
 > good choice as well (tho one we couldn't make, for other reasons).

That was for the coding system indicator in the modeline, where space
is at an extreme premium.  Note that this actually refers not to the
EOL convention, but rather to the path separator of the OS that
associates those EOL and path conventions.  Only true geeks will "get"
that!  (Especially the truly ancient Mac convention that only ling-
time Mac network administrators will recognize anymore.)

 > The advantage of unix/dos/mac over lf/cr/crlf is that it is "higher
 > level".

Which is, like, Just Wrong to even be thinking about.  This is a
facility that is needed only by repository and site administrators,
who need to be aware of low-level issues (cf. the "Makefile TAB" and
"MSVC project file EOL" issues).  Users who don't grasp the concept of
a line-terminating character, and thus are left no wiser than before
when faced with "lf/cr/crlf", want it to Just Work "at a high level".
They don't want to hear about portability problems because they only
work on one platform in the first place.  And both Python "universal
newlines" and Emacs/Mule EOL processing show that you can come very
close, even without solving the text file identification problem.

So the high-level problem is identifying text files, which is very
hard at the accuracy required for a VCS (again cf. the "Makefile TAB"
and "MSVC project file EOL" issues).  But once you've done that,
Unicode's line-breaking algorithm wins.

http://www.unicode.org/reports/tr14/

IMO what Bazaar should be aiming at is a flexible system that allows
users to treat binary files that look like text (Makefiles, project
files) as text, and do necessary conversions (project file EOLs) and
linting (Makefile tabs, which is necessarily heuristic) at the point
of commit.