From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.devel Subject: Re: decode_eol and inconsistent EOL Date: Mon, 29 Apr 2002 21:38:11 +0300 Sender: emacs-devel-admin@gnu.org Message-ID: <7458-Mon29Apr2002213811+0300-eliz@is.elta.co.il> References: <200204291302.g3TD2qB19466@rum.cs.yale.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1020105577 4285 127.0.0.1 (29 Apr 2002 18:39:37 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 29 Apr 2002 18:39:37 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 172G3l-000170-00 for ; Mon, 29 Apr 2002 20:39:37 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 172G7d-00050i-00 for ; Mon, 29 Apr 2002 20:43:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 172G3S-0000KF-00; Mon, 29 Apr 2002 14:39:18 -0400 Original-Received: from balder.inter.net.il ([192.114.186.15]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 172G2q-0000IQ-00 for ; Mon, 29 Apr 2002 14:38:40 -0400 Original-Received: from Zaretsky ([80.230.2.40]) by balder.inter.net.il (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id BJL92275; Mon, 29 Apr 2002 21:38:33 +0300 (IDT) Original-To: gildea@stop.mail-abuse.org, emacs-devel@gnu.org X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9 In-Reply-To: <200204291302.g3TD2qB19466@rum.cs.yale.edu> (monnier+gnu/emacs@rum.cs.yale.edu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:3417 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3417 > From: "Stefan Monnier" > 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.