On 2001-08-01 00:33:21 Branko Čibej wrote:
>> If this property is present on a given non-binary file, its value
>> is used to determine how line-endings should be translated.
>> Values for this can be:
>> 'native' - Use the line ending mechanism native
>> to the user's operating system.
>> 'dos', 'unix', or 'mac' - Use CRLF, LF, or LFCR, respectively.
>I'm not sure what the correct 'mac' line ending is. Have to check that.
>There are (used to be?) systems where lines are delimited from both
>ends. On VMS, a line started with a LF and ended with a CR, IIRC. How
>about a more generic approach: the value of this property is a pair of
>strings, one for the BOL and one for the EOL marker. 'native' would
>still have the same meaning, while 'dos', 'unix' and 'mac' would be
>aliases for ':\r\n', ':\n' and ':\n\r' (or whatever), respectively. A
>VMS guy would make 'native' an alias for '\n:\r'.
It's probably best not to use "\n" and "\r" because "\n" is ambiguous.
To a Mac programmer, for instance, it means a CR, and to a Windows
programmer it means CRLF - maybe not in C, but certainly in Perl.
Stick to numeric values.
>(And someone porting SVN to the ZX Spectrum will define 'native' as
>':\r' -- then run out of memory when compiling neon :-)
>> Absence of this property means that no line-ending substitution
>> should occur at all.
>Um. I'd rather use 'none' (':', if you accept the idea outlined above),
>and make 'native' the default for text files
Agreed - it's better to be explicit.
Another thought: don't assume a file is binary just because it doesn't
have any CR or LF characters! It might use the Unicode line separator
LS (2028) or paragraph separator PS (2029), Or even EBCDIC NEL,
which is in Unicode as 0085. This is all discussed at:
May I suggest LS as the repository's native newline character?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 21 14:36:34 2006