bug#1183: 23.0.60; ediff-buffers is broken

[Michael Kifer]

On Fri, 17 Oct 2008 11:35:46 -0700
"Drew Adams" <drew.adams@oracle.com> 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.