Re: EOL: unix/dos/mac

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <address@hidden>

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

Currently NLFs *are* displayed, if they don't match the default for
the buffer.  Some even appear as glyphs (^M in -unix buffers).  Sure,
there's no issue with fonts.  There are worse things than getting the
wrong font, though.

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

Because you have to fix pretty much everything, and new syntax will be
required for stuff like zap-to-char and nearly required for regexps.
Code will be massively uglified with tests for variable-length
sequences instead of single characters, everything from motion to
insdel will have to be modified.  Any code handling old-style hidden
lines (with CR marking "invisible" lines) will have to be changed.
It's not obvious to me that there are no counterintuitive
implications.  Opposed to that, there are very few text files with
mixed line endings, and in many cases the user would actually like to
have them regularized (at a time of their choosing, so they can have a
commit with only whitespace changes, for example).

 > Surely, going again through the pain of inadvertent changes to user
 > files is a movie we don't want to be part of again.

What pain of inadvertant changes?  Sure, there will likely be bugs in
the first draft of such code, what else is new?  If you're talking
specifically about the \201 regression, that's a completely different
issue AFAICT -- that was about buffer-as-unibyte exposing the
*internal* representation to Lisp, which was a "Mr. Foot, may I
introduce to you Mr. Bullet" kind of idea from Day 1.

 > >  > 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 don't think so.  It can be implemented as two functions, one run
just after decoding text from an external encoding, and one run just
before encoding text to an external encoding.  Done efficiently it can
probably be applied to saving autosave files as well, removing the
fragility.  For maximum safety the information about non-default NLFs
could be kept in "no-see-'um" properties accessed by separate APIs so
that users and programs don't accidentally delete the information.

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

I think you're hearing monsters in the closet.  Sure, that *could*
happen but code that does so is buggy IMO.  If that's not a good
enough answer, "no-see-'um" properties as described above would do the
trick.  I suspect that operations that change properties are rare
enough that putting a check for a "don't change me" flag into the
normal text property operations would not be an efficiency hit.