bug#1183: 23.0.60; ediff-buffers is broken

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 17 Oct 2008 23:17:31 -0400
> From: Michael Kifer <kifer@cs.sunysb.edu>
> Cc: "'Eli Zaretskii'" <eliz@gnu.org>, <monnier@iro.umontreal.ca>,
>         <1183@emacsbugs.donarmstrong.com>, <bug-gnu-emacs@gnu.org>,
>         <kifer@cs.stonybrook.edu>
> 
> 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.

The right encoding in Emacs 23 is utf-8-emacs-unix.  The problem with
that is that ediff-exec-process then uses raw-text to read the output
from Diff back into Emacs.  While raw-text is probably OK for reading
Diff output from comparing _files_, I'm afraid it will not be TRT for
reading output from comparing 2 temporary files encoded in
utf-8-emacs-unix.  If my fears are justified, I guess we will have to
modify ediff-exec-process so as to use utf-8-emacs-unix when
ediff-job-name has "buffers" in it.

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

Yes, but will hitting "*" help for Drew's use-case?  AFAIU, it will
"magically" show only the textual diffs, with no real explanation how
come the original display shows that every line is different, is that
right?

(Btw, "M-x ediff" actually does not pass the --binary switch to Diff,
so the original Ediff display is actually what Drew wanted, but let's
say we are doing the same on Unix, where changes in the EOL format are
reported by Diff as differences by default.)

> Back then Stefan suggested emacs-mule instead of no-conversion, but for some
> reason this was not done--don't remember why.

No special reason.

> He also said that things will change in emacs 23, but I did not
> follow that development.

See above.  I see that Stefan introduced emacs-internal into the Emacs
22 branch, but I don't see it on the trunk yet.  If and when it
arrives, we should use that one instead.