From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#1183: 23.0.60; ediff-buffers is broken Date: Fri, 17 Oct 2008 14:38:46 +0200 Message-ID: References: <00a101c92fbf$998d19b0$c2b22382@us.oracle.com> <00eb01c92fd0$1be49cc0$c2b22382@us.oracle.com> Reply-To: Eli Zaretskii , 1183@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1224247926 14274 80.91.229.12 (17 Oct 2008 12:52:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Oct 2008 12:52:06 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org, Michael Kifer To: 1183@emacsbugs.donarmstrong.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 17 14:53:01 2008 connect(): Connection refused Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Kqop3-00087e-Kj for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 Oct 2008 14:52:54 +0200 Original-Received: from localhost ([127.0.0.1]:40529 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kqony-0004xO-7r for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 Oct 2008 08:51:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KqomM-0004Sa-Dj for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 08:50:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KqomK-0004RZ-Ku for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 08:50:06 -0400 Original-Received: from [199.232.76.173] (port=46088 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KqomK-0004RS-GY for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 08:50:04 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:37492) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KqomJ-0000Ze-RU for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 08:50:04 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m9HCo0dJ031114; Fri, 17 Oct 2008 05:50:00 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m9HCj3qL030058; Fri, 17 Oct 2008 05:45:03 -0700 X-Loop: don@donarmstrong.com Resent-From: Eli Zaretskii Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Fri, 17 Oct 2008 12:45:03 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 1183 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by submit@emacsbugs.donarmstrong.com id=B.122424713328741 (code B ref -1); Fri, 17 Oct 2008 12:45:03 +0000 Original-Received: (at submit) by emacsbugs.donarmstrong.com; 17 Oct 2008 12:38:53 +0000 Original-Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m9HCcnfC028734 for ; Fri, 17 Oct 2008 05:38:50 -0700 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KqobR-0000zD-BH for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 08:38:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KqobP-0000z1-PR for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 08:38:48 -0400 Original-Received: from [199.232.76.173] (port=50120 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KqobP-0000yy-K4 for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 08:38:47 -0400 Original-Received: from mtaout1.012.net.il ([84.95.2.1]:21622) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KqobP-0006JL-NR for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 08:38:47 -0400 Original-Received: from HOME-C4E4A596F7 ([77.127.24.3]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K8V00FJCV6Y7G10@i-mtaout1.012.net.il> for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 14:40:11 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 X-CrossAssassin-Score: 2 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Fri, 17 Oct 2008 08:50:05 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:21597 Archived-At: > Date: Thu, 16 Oct 2008 23:15:45 +0200 > From: Eli Zaretskii > Cc: 1183@emacsbugs.donarmstrong.com, bug-gnu-emacs@gnu.org, > emacs-pretest-bug@gnu.org > > > From: "Drew Adams" > > Cc: , > > Date: Thu, 16 Oct 2008 13:45:21 -0700 > > > > > If so, this is expected: > > > > Well it certainly isn't expected in Emacs 20, 21, or 22, where ediff-buffers > > works perfectly for these two files. Why this change for Emacs 23? What's the > > gain? > > Sorry, you are right: Emacs 22 also uses --binary, but doesn't expose > this problem. So I guess something else is at work here. I'll look > closer when I have time. Found the culprit. It's in ediff-make-temp-file: (let* ( ... (coding-system-for-write (ediff-with-current-buffer buff (if (boundp 'buffer-file-coding-system) buffer-file-coding-system ediff-coding-system-for-write))) This let-binds the coding-system with which we will write the two buffers to temporary files, to the original encoding of the files read into the buffers being compared. The temporary files are then submitted to Diff, and that makes each line compare different because of the different EOL format. Emacs 22 unconditionally uses ediff-coding-system-for-write here, which is set to `no-conversion', so this problem does not happen in Emacs 22. This change was made in Aug 2007, and Michael Kifer wrote a bit later on emacs-devel that using no-conversion was screwing some other use-case (I couldn't find the description of that use-case, although Michael said it was reported earlier on emacs-devel). I could easily fix this particular problem by forcing the EOL conversion to -unix, but I think there's a broader issue here, and we might as well handle it now. The issue is this: suppose we have two buffers whose text is identical in the internal Emacs representation of characters, but whose values of buffer-file-coding-system differ-- do we want such buffers to compare equal or not? For example, the buffers could contain Latin-2 text, with one buffer coming from a file encoded in ISO-8859-2, the other coming from a UTF-8 file. The current Ediff code will compare these buffers different. If we want them to compare equal instead, this means that `ediff' and `ediff-buffers' will produce different results for the same two files. The different EOL format is just a special case of this general problem. In a discussion in Oct 2007, Stefan said that using the buffer's encoding is wrong, see: http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg01381.html Stefan wanted to use the equivalent of emacs-mule for Emacs 23 instead of buffer's encoding, but do we have such an encoding now? Is no-conversion-multibyte it? Or maybe utf-8 is good enough? But first, we should decide whether we want such buffers to compare equal or not. We could also let them compare equal, but display a message to the effect that the buffers define different encoding for saving them to files. Opinions?