bug#1183: 23.0.60; ediff-buffers is broken

["Drew Adams" <drew.adams@oracle.com>]

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

It's OK for ediff-buffers to be more refined than before, to be able to take
into account current encodings etc. for the buffers, but it should inform the
user of the situation and let the user, if s?he wants, proceed to compare the
buffers using the same encodings etc. - or whatever is necessary to see the
actual textual differences, beyond encoding etc. differences.

The same behavior as previously (Emacs 22) should be available as a user choice
if the only differences are line endings, encodings, etc. And such differences
as line endings should at least be treated as differences and shown as such.
It's no good to just say the buffers are different, without offering more info
than that.

IOW, ediff-buffers should be at least as useful as it was before. Adding coding
diffs should be a plus, not a minus. Simply punting, showing a single giant diff
with no possible refinement and no explanation, is not helpful.

> > 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?
> 
> That would be fine, indeed.

Fine, but not enough. If a user wants to see the textual differences between the
two buffers, the info that the encodings are different is not helpful enough to
get the job done. In the case described, there are real textual differences (an
added Lisp sexp), and ediff-buffers is not at all helpful in showing them.