From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Kifer Newsgroups: gmane.emacs.bugs Subject: bug#1183: 23.0.60; ediff-buffers is broken Date: Fri, 17 Oct 2008 23:17:31 -0400 Organization: Stony Brook University Message-ID: <20081017231731.28a0382f@kiferserv> 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> Reply-To: kifer@cs.sunysb.edu, 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 1224300623 10247 80.91.229.12 (18 Oct 2008 03:30:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Oct 2008 03:30:23 +0000 (UTC) Cc: 1183@emacsbugs.donarmstrong.com, kifer@cs.stonybrook.edu, bug-gnu-emacs@gnu.org To: "Drew Adams" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 18 05:31: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 1Kr2XA-0006mL-36 for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Oct 2008 05:31:20 +0200 Original-Received: from localhost ([127.0.0.1]:47681 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kr2W4-00049K-Sy for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 Oct 2008 23:30:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kr2W0-00046i-9P for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 23:30:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kr2Vz-00045p-Ju for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 23:30:07 -0400 Original-Received: from [199.232.76.173] (port=48107 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kr2Vz-00045W-Fk for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 23:30:07 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:40363) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kr2Vz-0006Nz-AW for bug-gnu-emacs@gnu.org; Fri, 17 Oct 2008 23:30:07 -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 m9I3U0fT024351; Fri, 17 Oct 2008 20:30:00 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m9I3P5cR023370; Fri, 17 Oct 2008 20:25:05 -0700 X-Loop: don@donarmstrong.com Resent-From: Michael Kifer Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 18 Oct 2008 03:25: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.122429985722003 (code B ref 1183); Sat, 18 Oct 2008 03:25:04 +0000 Original-Received: (at 1183) by emacsbugs.donarmstrong.com; 18 Oct 2008 03:17:37 +0000 Original-Received: from sbcs.cs.sunysb.edu (sbcs.cs.sunysb.edu [130.245.1.15]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m9I3HXm3021996 for <1183@emacsbugs.donarmstrong.com>; Fri, 17 Oct 2008 20:17:34 -0700 Original-Received: from kiferserv (compserv1 [130.245.1.44]) by sbcs.cs.sunysb.edu (8.13.6/8.12.11) with ESMTP id m9I3HUWF000827; Fri, 17 Oct 2008 23:17:30 -0400 (EDT) In-Reply-To: <004901c93087$2c0345e0$0200a8c0@us.oracle.com> X-Mailer: Claws Mail 3.6.1 (GTK+ 2.12.9; i486-pc-linux-gnu) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Fri, 17 Oct 2008 23:30:07 -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:21645 Archived-At: On Fri, 17 Oct 2008 11:35:46 -0700 "Drew Adams" wrote: > > > > > > > But first, we should decide whether we want such > > > > > > > buffers to compare equal or not. > > > > > > > > > > > > I believe we do, because it's called ediff-buffers. There's > > > > > > ediff-files for when you want to compare the files. > > > > > > > > > > That's terrible. Ediff-buffers has always been usable > > > > > directly for buffers visiting files also. > > > > > > > > I didn't see the original post, but the general idea was that > > > > whenever things look the same in Emacs they should be treated > > > > as equal (or equal module spaces). I do not think the user > > > > should be bothered with encodings. Copying from buffer > > > > to buffer should also be transparent. (And ediff-files and > > > > ediff-buffers should produce the same results.) > > > > > > > > Unfortunately, I have not been following the developments in > > > > the last few years, and my knowledge of the mechanics > > became rusty. > > > > > > Everything Michael said sounds right to me. > > > > Then why did you say "that's terrible" in response to Stefan who > > expressed the same view as Michael? They both say that what is > > _displayed_ the same in Emacs should compare equal in ediff-buffers. > > I guess I misunderstood. I thought that Stefan was saying that ediff-buffers > should continue to do what it is doing now: just show one big difference, with > no distinction of textual differences, and force users to use ediff-files to see > the textual differences. If he meant the same thing as Michael, then we agree. > > The two buffers I reported on should *not* compare equal, but neither should > ediff-buffers just throw up its hands and say only "they're different somehow". 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? > I mistakenly thought that Stefan was saying that ediff-buffers should not > distinguish their textual differences but should just report that they are > different (one big diff). IOW, I thought he was saying that the current > behavior > is correct for ediff-buffers but that ediff-files should, as always, show the > textual differences. > > > OTOH, "M-x ediff" that compares _files_ will still show differences > > for identical text encoded differently in each of the files. > > 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. > What I objected to was that textual differences were being effectively lost, > because ediff-buffers just displays one big diff with identical, full-buffer > highlighting - it doesn't show the textual differences at all. This was a misunderstanding.