From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.bugs Subject: Re: decode_eol and inconsistent EOL Date: Mon, 29 Apr 2002 08:59:44 -0400 Sender: bug-gnu-emacs-admin@gnu.org Message-ID: <200204291259.g3TCxi119424@rum.cs.yale.edu> References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1020085286 20871 127.0.0.1 (29 Apr 2002 13:01:26 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 29 Apr 2002 13:01:26 +0000 (UTC) Cc: Stefan Monnier , gnu-emacs-bug@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 172AmT-0005QW-00 for ; Mon, 29 Apr 2002 15:01:25 +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 172AmJ-00023c-00; Mon, 29 Apr 2002 09:01:15 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 172Akt-0001wX-00 for ; Mon, 29 Apr 2002 08:59:47 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g3TCxi119424; Mon, 29 Apr 2002 08:59:44 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Eli Zaretskii Errors-To: bug-gnu-emacs-admin@gnu.org X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.bugs:1023 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:1023 > > I think all that we really care about is that the load+save trip is safe > > and that the content of the Emacs buffer looks "as right as possible". > > The second part is the issue here: it's open to interpretation. I believe we've lost track of the problem. Do you agree with the patch below ? All it does is that if the auto-detection of eol has decided to use dos-style eol, then we use dos-style eols even if the file has some stray CRs characters. Of course, if there is an LF in the file which is not preceded by a CR, we revert to unix-style eol, as before. It is safe and does not change any heuristic. I don't think it's "open to interpretation" because it only changes the behavior when there are CRLFs in the file (otherwise the auto-detection would not have chosen dos-style eol) and when every LF is preceded by a CR which is a pretty clear indication that we're dealing with a dos-style file. Stefan --- coding.c.~1.241.~ Tue Apr 16 10:15:28 2002 +++ coding.c Fri Apr 26 09:09:16 2002 @@ -3173,11 +3173,6 @@ ONE_MORE_BYTE (c); if (c != '\n') { - if (coding->mode & CODING_MODE_INHIBIT_INCONSISTENT_EOL) - { - coding->result = CODING_FINISH_INCONSISTENT_EOL; - goto label_end_of_loop; - } src--; c = '\r'; }