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

[Jurgen Defurne]

On Tue, 31 Mar 2009 12:03:20 +0900
"Stephen J. Turnbull" <stephen at xemacs.org> wrote:

> 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.
> 

This is currently the best reply I read about the issue. I am interested in the direction bzr takes, because I would like to be able to replace Telelogic Continuus with it. One of the issues is about CR/CRLF, and last week we detected a problem with it because we are now working in a mixed Windows/Linux environment.

The issue is this. On a checkout, a user can choose ASCII translation on or off. For our Linux based projects, it should be off. Files are stored in unix format in the database. However, each file has a history. If a file used in a checkout is opened for viewing or editing, the ASCII translation setting takes precedence. However, if a file from the history is opened which is not part of a checkout, then the settings from the platform take precedence. In this case we had an issue with CRLF which got translated to CRCRLF. I must say, however, that the person responsible used Visual Studio, which seemed to have the nasty habit to save all files with CRLF. I do not know if he resolved the issue. Most other developers use Notepad++ or Codewright, which seem to be easier on this issue.

Regards,

Jurgen