Subject: bug#1183: 23.0.60; ediff-buffers is broken

From: "Drew Adams" <[email-masked]>
Date: Thu, 16 Oct 2008 13:45:21 -0700

> From: Eli Zaretskii Sent: Thursday, October 16, 2008 1:25 PM
> > From: "Drew Adams" <[email-masked]>
> > emacs -Q
> >  
> > Visit both the bookmark.el file from this installation (see 
> > below) and a copy of bookmark.el from CVS for today, 2008-10-16.
> >  
> > The only difference between the two files is in fact this text which
> > was added to the CVS version near the end of the file, just before
> > run-hooks:
> >  
> > (defun bookmark-unload-function ()
> >   "Unload the Bookmark library."
> >   (when bookmark-save-flag (bookmark-save))
> >   ;; continue standard unloading
> >   nil)
> >  
> > You can see this by using ediff in Emacs 22, 21, or 20 - or by using
> > diff.
> >  
> > However, ediff-buffers shows the entire buffers as a single 
> > diff, and hitting `*' to refine that diff has no effect at all. IOW,
> > ediff-buffers is now useless for seeing the differences 
> > between these two files.
> 
> I don't have the ``bookmark.el file from this installation'' (you
> didn't attach it),

Attached now. I didn't think I had to attach it since I referenced its build -
sorry.

> so I produced it manually by copying today's
> bookmark.el and then removing the function bookmark-unload-function.

Same diff. ;-)

> With these two files, I can only reproduce this with Emacs built on
> Windows from today's CVS if one of the files has Unix end-of-line
> format, while the other has DOS/Windows EOL format.  Is that your
> case?

I downloaded the CVS version (with Unix format) from
http://cvs.savannah.gnu.org/viewvc/emacs/emacs/lisp/bookmark.el?view=log by
clicking the first "download" link on the page. The other file was in the
distribution.

Yes, I guess it is my case: The CVS file has "(Unix)" in the mode line; the
installation file has nothing.

> 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?

And how to change the buffers (e.g. line endings) so ediff-buffers will compare
them correctly? And why wouldn't ediff-buffers itself do that automatically
(perhaps after user confirmation)?

> Ediff on Windows invokes the `diff' program
> with the --binary option (see ediff-diff-options), which makes all
> lines compare not equal due to the different line endings.

Not very useful in situations like this. Comparing source code files where the
only difference is line endings should not produce a totally unusable diff: a
single, whole-file diff for which `*' has no effect (cannot be refined). 

It should show just the line endings as differences, if they are the only
differences. And in this case, where several text lines were different, it
should pick those lines up as a difference. Definitely. 

To me, this seems horribly broken.

> You can see this by using `diff' directly from the shell's prompt,
> if you pass it the --binary option.
> 
> If both files have identical EOL format, Ediff produces the output
> you'd expect.

And how to get that identical EOL format (I should know that, but I never bother
to change the format).

And why shouldn't ediff at least pick that up and let you know how to get to a
useful diff. Better yet, it should do that for you, perhaps after asking for
confirmation to change line endings or whatever.

What was wrong with the Emacs 22, 21, 20,... behavior?

> (The reason for the --binary option is to allow comparison of buffers
> and files with non-ASCII text, which IMO is a much more important
> use-case than two almost identical files with different line endings.)

Apples and oranges. They are probably both important.

Certainly it's important to be able to diff a file in the installation against a
CVS version of the file in a simple way.

Line-ending differences are not the most important differences to show, and in
fact even those differences are not apparent. You cannot tell anything at all
from the ediff-buffers diff - it tells you nothing about the differences except
that there are differences. Pretty useless.

I can't believe that one would argue that this behavior represents progress, at
least in its present form. Something should be done to fix this, IMO.