[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS and unicode

From: Arno Schuring
Subject: Re: CVS and unicode
Date: Sun, 11 Sep 2005 23:33:00 +0200

Example: Data files from the Daimonin project (an MMORPG). They are ISO-8859-1
text files. They must explicitely only use LF for line ending. They won't
work with CR/LF. The file format is specified to be plain text with LF line
endings only. The server and editor will not accept files with CR/LF.
So even if somebody checks out a CVS sandbox on Windows, the line endings must
be LF, otherwise the files can't be used.

I'd say that they're not text files, in that they differ from the widely used (and accepted, though debatable) format of the OS. In the same way that...

[snip] CR/LF is a os-specific problem that's best handled in the text editor.

the program reading the text should be able to handle the appropriate line-endings for the platform. Otherwise, the program should not claim to read "text files". Rather, they are reading binary files with XX-terminated lines of text.

Even on Windows there are text editors capable of using NL only (gvim,
UltraEdit, Emacs, most IDEs and various others).

You seem to be primarily concerned with the utility to edit text files. How about all the programs that parse text files? Should programs that read their own configuration files be prepared to handle all possible line endings?

And how about the other way around? Should vi on unix be adapted to support CR/LF line endings? You certainly seem to suggest that it is wrong for windows editors to only support the OS' native line endings, so how about on unix?


But regardless, if a cvs client changes a file upon checkin or checkout other than keyword replacement or diff patching, it eventually breaks the file, see
above example.

I'd consider the app broken, not the text file.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]