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 20:43:27 -0700 Message-ID: <003601c930d3$aead3770$0200a8c0@us.oracle.com> References: <00a101c92fbf$998d19b0$c2b22382@us.oracle.com><00eb01c92fd0$1be49cc0$c2b22382@us.oracle.com><002501c93078$21bf8c60$0200a8c0@us.oracle.com><20081017130533.3c3070bc@kiferserv><002a01c9307c$3af9fef0$0200a8c0@us.oracle.com><004901c93087$2c0345e0$0200a8c0@us.oracle.com> <20081017231731.28a0382f@kiferserv> 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 1224303022 14161 80.91.229.12 (18 Oct 2008 04:10:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Oct 2008 04:10:22 +0000 (UTC) Cc: 1183@emacsbugs.donarmstrong.com, kifer@cs.stonybrook.edu, bug-gnu-emacs@gnu.org To: Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 18 06:11:22 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 1Kr39t-0004Ol-BJ for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Oct 2008 06:11:22 +0200 Original-Received: from localhost ([127.0.0.1]:35667 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kr38l-0008B1-OB for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Oct 2008 00:10:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kr38g-00089h-JE for bug-gnu-emacs@gnu.org; Sat, 18 Oct 2008 00:10:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kr38e-00088u-TD for bug-gnu-emacs@gnu.org; Sat, 18 Oct 2008 00:10:06 -0400 Original-Received: from [199.232.76.173] (port=46825 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kr38e-00088p-Q1 for bug-gnu-emacs@gnu.org; Sat, 18 Oct 2008 00:10:04 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:37215) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kr38e-0001Qe-DY for bug-gnu-emacs@gnu.org; Sat, 18 Oct 2008 00:10:05 -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 m9I4A0pK002134; Fri, 17 Oct 2008 21:10:00 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m9I3o5am029378; Fri, 17 Oct 2008 20:50:05 -0700 X-Loop: don@donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 18 Oct 2008 03:50: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.122430142828012 (code B ref 1183); Sat, 18 Oct 2008 03:50:04 +0000 Original-Received: (at 1183) by emacsbugs.donarmstrong.com; 18 Oct 2008 03:43:48 +0000 Original-Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m9I3hjnB028006 for <1183@emacsbugs.donarmstrong.com>; Fri, 17 Oct 2008 20:43:46 -0700 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m9I3hQTi012038; Fri, 17 Oct 2008 21:43:26 -0600 Original-Received: from acsmt703.oracle.com (acsmt703.oracle.com [141.146.40.81]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m9I3hL9H013799; Fri, 17 Oct 2008 21:43:22 -0600 Original-Received: from dradamslap1 (/24.23.165.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Oct 2008 20:43:21 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20081017231731.28a0382f@kiferserv> Thread-Index: Ackw0FQnzEcr1E04Ss6Q/sML0lry7QAAs+Og 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: Sat, 18 Oct 2008 00:10:06 -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:21648 Archived-At: > To make it clear, nobody was saying that the two buffers > should be compared > equal. The issue is: how do we make diff (NOT ediff) to > recognize that these > buffers are nearly identical modulo some minor stuff? > > Ediff-buffers does almost the right thing (at least, was > doing until things > changed in emacs). It would save the buffers in temp files > using the *same* > encoding, so all that crap is pushed out of the way. Then it > would run diff on > the temp files. Since the encodings are the same, diff would > find what is > different and then ediff will display that. (With all its > complexity, ediff is > just a front-end for diff.) So, for ediff-buffers, the > question is which > encoding to use. > > For ediff-files things seem to be worse: it runs diff on the > original files, so > if one has DOS line endings and the other does not then it > all depends on what > diff does. This is why sometimes you run ediff files on 2 > files that are > nearly identical and get one big diff region equal to the entire file. > This is a bit annoying, but not too bad, since hitting * > should fix the > problem: it would save the diff regions using the same > encoding and will run > diff over them. > > So, basically, it boils down to choosing the right encoding. > I am not sure which is right. > Long time ago, it was decided to use no-conversion. Then > someone found a bad > case and suggested to use the buffer coding system *if* it is set. > This seemed to work better, but still had some problems. > > Back then Stefan suggested emacs-mule instead of > no-conversion, but for some > reason this was not done--don't remember why. He also said > that things will > change in emacs 23, but I did not follow that development. > > What has changed in emacs 23 with respect to this issue? > > > Again, I have no problem with ediff commands also showing > > or otherwise identifying encoding differences. > > See above. The point was not that textual diffs should be > lost, but that it should be made possible for the diff program > to recognize identical regions > (modulo dos line endings, etc) as such. Got it. Thanks for a clear description. Sorry for having misunderstood. FWIW, the need to hit `*' to refine for ediff in the situation you describe has been true for a while, and it is no big deal. Generally, highlighting just the differences is easier to read, but highlighting everything and then refining is OK too, if need be. Thanks to all for working on this.