Re: EOL: unix/dos/mac

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden,
>     address@hidden,
>     address@hidden
> Date: Tue, 26 Mar 2013 16:45:30 +0900
> 
> Eli Zaretskii writes:
>  > > From: "Stephen J. Turnbull" <address@hidden>
> 
>  > > [Unicode] just says "all of these sequences when encountered in
>  > > text purporting to conform to this standard should be treated in
>  > > the same way."  Emacsen should do the same.
>  > 
>  > That would require Emacs to store all the possible EOL sequences in
>  > the buffer, and treat them all identically.  That's doable, but is a
>  > non-trivial job; volunteers are welcome.
> 
> I don't know what you mean by "all the possible EOL sequences".  It's
> well-defined (in Unicode TR#13 or section 5.8 of Unicode 6.2) what an
> NLF is: it's the first of CRLF, LF, CR, or NL (U+0085) that matches
> when parsing a line.

That's what I meant: any of the possible NLF.

>  > > The question then is how to deal with file comparison.  We'd like to
>  > > avoid creating spurious diffs based on "fixing" random different line
>  > > endings
>  > 
>  > If Emacs is to support different EOL formats in the same file, it
>  > should not convert them at all.
> 
> Of course it should convert them.
> 
> Trying to support multiple EOL codings in the buffer is craziness.

But it's the only way to be 100% sure you don't introduce spurious
changes into files.  And since newlines, unlike characters, are not
displayed, there's no issues with fonts etc. here.  So "craziness"
sounds like exaggeration to me, although I do agree that making this
happen is not a trivial job.

> Doing it only for EOLs would be much less painful, but it's not
> worth it.

Please explain why do you think it isn't worth it.  Surely, going
again through the pain of inadvertent changes to user files is a movie
we don't want to be part of again.

>  > Anything else _will_ introduce spurious modifications, and could
>  > even corrupt some files, if the exact EOL sequence here or there
>  > matters.
> 
> No, it need not, any more than any ambiguous encoding need do so.  Of
> course it will be fragile if (for example) Emacs crashes and you have
> to recover an autosave file.

It will be fragile, and subtle bugs will tend to break quite a bit.

>  > > I guess one could attach a text property to newlines differing from
>  > > the file's autodetected EOL convention.
>  > 
>  > Not sure how a text property should help here.
> 
> It would mark non-default EOL sequences for correct output.

And when text properties are removed by some operation on a buffer,
what then?  I don't think this is reliable enough to ensure we don't
change user files where the user didn't edit them.