From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#1183: 23.0.60; ediff-buffers is broken Date: Fri, 17 Oct 2008 07:36:33 -0700 Message-ID: <002901c93065$c1da2920$0200a8c0@us.oracle.com> References: <00a101c92fbf$998d19b0$c2b22382@us.oracle.com> <00eb01c92fd0$1be49cc0$c2b22382@us.oracle.com> Reply-To: Drew Adams , 1183@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1224255041 9152 80.91.229.12 (17 Oct 2008 14:50:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Oct 2008 14:50:41 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org, 'Michael Kifer' To: "'Eli Zaretskii'" , <1183@emacsbugs.donarmstrong.com> Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 17 16:51:39 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 1Kqqfd-0005BG-Ju for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 Oct 2008 16:51:18 +0200 Original-Received: from localhost ([127.0.0.1]:52865 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KqqeY-0007fM-8E for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 Oct 2008 10:50:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KqqeV-0007ey-Bl for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 10:50:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KqqeR-0007e5-NB for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 10:50:05 -0400 Original-Received: from [199.232.76.173] (port=46708 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KqqeR-0007dp-9g for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 10:50:03 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:46831) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KqqeQ-0000WW-MC for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 10:50:03 -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 m9HEo0D0029292; Fri, 17 Oct 2008 07:50:00 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m9HEj4c4028273; Fri, 17 Oct 2008 07:45:04 -0700 X-Loop: don@donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Fri, 17 Oct 2008 14:45:04 +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 1183-submit@emacsbugs.donarmstrong.com id=B1183.122425421326845 (code B ref 1183); Fri, 17 Oct 2008 14:45:04 +0000 Original-Received: (at 1183) by emacsbugs.donarmstrong.com; 17 Oct 2008 14:36:53 +0000 Original-Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m9HEaogC026837 for <1183@emacsbugs.donarmstrong.com>; Fri, 17 Oct 2008 07:36:51 -0700 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m9HEaaHv004244; Fri, 17 Oct 2008 09:36:36 -0500 Original-Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m9HEaYjS021064; Fri, 17 Oct 2008 08:36:34 -0600 Original-Received: from dradamslap1 (/24.23.165.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Oct 2008 07:36:34 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AckwVXf65iOUMbyXSdCCUfxG9+AecAAD3fAA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Fri, 17 Oct 2008 10: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:21605 Archived-At: > From: Eli Zaretskii Sent: Friday, October 17, 2008 5:39 AM > > > > 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? I don't have much of an opinion because of ignorance in this area. If you are asking whether ediff should treat buffers as different when they differ only by encoding or line endings, I'd say probably yes and know: It would be good to give the user all knowledge that ediff has, and then let the user control how to compare. A message could let the user know about line-ending differences, for example, and ask if you want to compare using only Emacs's internal encoding (or whatever the correct terminology is) - that is, ignoring just the line-ending difference. IOW, give the user the knowledge and control. What's unacceptable is for Emacs to throw up its hands and just say the two are different, without saying/showing how they differ. The user should be able to drill down and see all possible differences, perhaps showing different kinds of differences in different ways. I'll leave the rest to you guys who know about this stuff. You get the drift of what's missing/wrong. Thx.