From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: decode_eol and inconsistent EOL Date: Mon, 29 Apr 2002 15:41:21 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200204291941.g3TJfME27696@rum.cs.yale.edu> References: <200204291840.g3TIe7306365@aztec.santafe.edu> <9743-Mon29Apr2002221339+0300-eliz@is.elta.co.il> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1020109360 12349 127.0.0.1 (29 Apr 2002 19:42:40 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 29 Apr 2002 19:42:40 +0000 (UTC) Cc: rms@gnu.org, gildea@stop.mail-abuse.org, emacs-devel@gnu.org, akochoi@shaw.ca Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 172H2m-0003D4-00 for ; Mon, 29 Apr 2002 21:42:40 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 172H6g-0006Ra-00 for ; Mon, 29 Apr 2002 21:46:42 +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 172H2R-0007Pm-00; Mon, 29 Apr 2002 15:42:19 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 172H1Z-0007Ly-00; Mon, 29 Apr 2002 15:41:25 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g3TJfME27696; Mon, 29 Apr 2002 15:41:22 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: "Eli Zaretskii" 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:3427 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3427 > The other behavior inhibits all EOL conversions, so it shows the > contents of a binary file's more accurately. That's not an > overwhelming advantage, but I don't see any significant advantages in > the suggested change, either. In the absence of significant > advantages, I think the defaults should not change. The advantage is that it allows the inclusion of lone CR chars in dos-style files and it makes the code simpler. Binary file whose first "three lines" look like dos-style files are much less frequent in my experience than broken text files (probably because CRLF are frequently converted to/from LF, so it's quite common to end up with an extra CR or a missing CR. For technical reasons Emacs can't handle a lone LF in a dos-style file, but that's not the case for lone CRs). I've wasted too much of my time on this detail anyway. Stefan