Re: decode_eol and inconsistent EOL

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/address@hidden>
> Date: Mon, 29 Apr 2002 09:02:52 -0400
> 
> No, please check again.

I did, believe me.  (Btw, I think there's at least one more place in
coding.c that needs a similar change, should we install this.)

> All I do is that we switch from dos->unix a bit less often.  Mac is
> completely unaffected.

I believe there's a misunderstanding: you are talking about Mac EOL
type, while I was thinking about Mac _users_.

A file on a Mac can be auto-detected as a DOS-style file.  Since
auto-detection only examines the first 3 lines, it could err,
especially with files whose EOLs are inconsistent.  When
auto-detection yields DOS EOL style, your patch _will_ affect
user-level behavior.  If and when that happens, Windows users might
not mind, since DOS EOLs are their ``native'' style.  But I wonder
whether Mac users will see this the same way.

More generally, it is not clear to me why is it better to remove one
CR before each LF, but leave the other in the buffer.  Either way, the
display is ugly, and it's clear that something is wrong.  However,
while with the current code the two CRs will clearly show the problem,
with the change you suggest users might become confused (``why did
Emacs display the CRs even though the mode line says "(DOS)"?'').

I understand that sometimes the effect of this change is desirable;
Stephen's case is one such situation.  However, for the
above-mentioned reasons, I think a decision whether this is
appropriate is a burden best left to the user, especially since
Mule-related changes tend to cause unintended consequences.  That is
why a user option like dos-eols-okay-even-if-we-find-stray-CRs sounds
like a better way to solve this.  Perhaps we should even have a more
general always-honor-detected-eol-style option, which would disable
the current logic of reverting to unconverted EOLs if inconsistency is
found.