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 10:42:33 +0200 Message-ID: <83vc8ezh52.fsf@gnu.org> References: <87ip4fc4xd.fsf@uwakimon.sk.tsukuba.ac.jp> <831ub21xpn.fsf@gnu.org> <87620ed2p1.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1364287354 32267 80.91.229.3 (26 Mar 2013 08:42:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Mar 2013 08:42:34 +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 09:43:00 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 1UKPT9-0001P5-Oz for ged-emacs-devel@m.gmane.org; Tue, 26 Mar 2013 09:42:59 +0100 Original-Received: from localhost ([::1]:34167 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKPSl-0007ox-VC for ged-emacs-devel@m.gmane.org; Tue, 26 Mar 2013 04:42:35 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53607) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKPSd-0007gd-6D for emacs-devel@gnu.org; Tue, 26 Mar 2013 04:42:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKPSa-0007Tp-JX for emacs-devel@gnu.org; Tue, 26 Mar 2013 04:42:26 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:37803) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKPSa-0007TP-Bz for emacs-devel@gnu.org; Tue, 26 Mar 2013 04:42:24 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MK900900ENM8200@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 26 Mar 2013 10:42:21 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MK900924EUK6540@a-mtaout22.012.net.il>; Tue, 26 Mar 2013 10:42:21 +0200 (IST) In-reply-to: <87620ed2p1.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.172 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:158193 Archived-At: > From: "Stephen J. Turnbull" > Cc: per.starback@gmail.com, > monnier@iro.umontreal.ca, > emacs-devel@gnu.org > Date: Tue, 26 Mar 2013 16:45:30 +0900 > > Eli Zaretskii writes: > > > From: "Stephen J. Turnbull" > > > > [Unicode] just says "all of these sequences when encountered in > > > text purporting to conform to this standard should be treated in > > > the same 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. > > I don't know what you mean by "all the possible EOL sequences". It's > well-defined (in Unicode TR#13 or section 5.8 of Unicode 6.2) what an > NLF is: it's the first of CRLF, LF, CR, or NL (U+0085) that matches > when parsing a line. That's what I meant: any of the possible NLF. > > > The question then is how to deal with file comparison. We'd like to > > > avoid creating spurious diffs based on "fixing" random different line > > > endings > > > > If Emacs is to support different EOL formats in the same file, it > > should not convert them at all. > > Of course it should convert them. > > Trying to support multiple EOL codings in the buffer is craziness. But it's the only way to be 100% sure you don't introduce spurious changes into files. And since newlines, unlike characters, are not displayed, there's no issues with fonts etc. here. So "craziness" sounds like exaggeration to me, although I do agree that making this happen is not a trivial job. > Doing it only for EOLs would be much less painful, but it's not > worth it. Please explain why do you think it isn't worth it. Surely, going again through the pain of inadvertent changes to user files is a movie we don't want to be part of again. > > Anything else _will_ introduce spurious modifications, and could > > even corrupt some files, if the exact EOL sequence here or there > > matters. > > No, it need not, any more than any ambiguous encoding need do so. Of > course it will be fragile if (for example) Emacs crashes and you have > to recover an autosave file. It will be fragile, and subtle bugs will tend to break quite a bit. > > > 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. > > It would mark non-default EOL sequences for correct output. And when text properties are removed by some operation on a buffer, what then? I don't think this is reliable enough to ensure we don't change user files where the user didn't edit them.