From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: EOL: unix/dos/mac Date: Tue, 26 Mar 2013 08:28:36 +0200 Message-ID: <831ub21xpn.fsf@gnu.org> References: <87ip4fc4xd.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1364279316 27939 80.91.229.3 (26 Mar 2013 06:28:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Mar 2013 06:28:36 +0000 (UTC) Cc: per.starback@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 26 07:29:01 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UKNNQ-0006b9-I7 for ged-emacs-devel@m.gmane.org; Tue, 26 Mar 2013 07:28:56 +0100 Original-Received: from localhost ([::1]:52851 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKNN2-0001wu-Js for ged-emacs-devel@m.gmane.org; Tue, 26 Mar 2013 02:28:32 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKNMz-0001wp-6p for emacs-devel@gnu.org; Tue, 26 Mar 2013 02:28:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKNMw-0002nZ-PA for emacs-devel@gnu.org; Tue, 26 Mar 2013 02:28:29 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:42015) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKNMw-0002nL-H4 for emacs-devel@gnu.org; Tue, 26 Mar 2013 02:28:26 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MK90090087KDQ00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Tue, 26 Mar 2013 08:28:24 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MK90097F8NCEC00@a-mtaout21.012.net.il>; Tue, 26 Mar 2013 08:28:24 +0200 (IST) In-reply-to: <87ip4fc4xd.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:158187 Archived-At: > From: "Stephen J. Turnbull" > Date: Tue, 26 Mar 2013 10:42:38 +0900 > Cc: Per Starb=C3=A4ck , emacs-devel@gnu.org >=20 > Stefan Monnier writes: >=20 > > BTW, in this same area, it would be good to detect and indicate > > prominently "Unix with some CRLFs", also known as "mixed-line-en= ding", > > which is often misunderstood as "my Emacs fails to recognize my = CRLF > > file". >=20 > Unicode doesn't care, you know: it considers all ASCII line breaks = and > terminators to be the same thing (NEW LINE FUNCTION). I haven't re= ad > that part of the standard in a long time, but IIRC, although many > people interpolate "according to platform", Unicode doesn't care ab= out > that, it just says "all of these sequences when encountered in text > purporting to conform to this standard should be treated in the sam= e > way." Emacsen should do the same. That would require Emacs to store all the possible EOL sequences in the buffer, and treat them all identically. That's doable, but is a non-trivial job; volunteers are welcome. > The question then is how to deal with file comparison. We'd like t= o > avoid creating spurious diffs based on "fixing" random different li= ne > endings If Emacs is to support different EOL formats in the same file, it should not convert them at all. Anything else _will_ introduce spurious modifications, and could even corrupt some files, if the exact EOL sequence here or there matters. > 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. > I've also considered switching the internal representation of newli= ne > to U+2028 LINE SEPARATOR What good would that be?