bug#1183: 23.0.60; ediff-buffers is broken

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

> From: Eli Zaretskii Sent: Friday, October 17, 2008 5:39 AM
> > > > 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?
> > 
> > Sorry, you are right: Emacs 22 also uses --binary, but 
> > doesn't expose this problem.  So I guess something else is
> > at work here.  I'll look closer when I have time.
> 
> Found the culprit.  It's in ediff-make-temp-file:
> 
>   (let* ( ...
>   	 (coding-system-for-write
> 	  (ediff-with-current-buffer buff
> 	    (if (boundp 'buffer-file-coding-system)
> 		buffer-file-coding-system
> 	      ediff-coding-system-for-write)))
> 
> This let-binds the coding-system with which we will write the two
> buffers to temporary files, to the original encoding of the files read
> into the buffers being compared.  The temporary files are then
> submitted to Diff, and that makes each line compare different because
> of the different EOL format.
> 
> Emacs 22 unconditionally uses ediff-coding-system-for-write here,
> which is set to `no-conversion', so this problem does not happen in
> Emacs 22.
> 
> This change was made in Aug 2007, and Michael Kifer wrote a bit later
> on emacs-devel that using no-conversion was screwing some other
> use-case (I couldn't find the description of that use-case, although
> Michael said it was reported earlier on emacs-devel).
> 
> I could easily fix this particular problem by forcing the EOL
> conversion to -unix, but I think there's a broader issue here, and we
> might as well handle it now.  The issue is this: suppose we have two
> buffers whose text is identical in the internal Emacs representation
> of characters, but whose values of buffer-file-coding-system differ--
> do we want such buffers to compare equal or not?  For example, the
> buffers could contain Latin-2 text, with one buffer coming from a file
> encoded in ISO-8859-2, the other coming from a UTF-8 file.
> 
> The current Ediff code will compare these buffers different.  If we
> want them to compare equal instead, this means that `ediff' and
> `ediff-buffers' will produce different results for the same two files.
> 
> The different EOL format is just a special case of this general
> problem.
> 
> In a discussion in Oct 2007, Stefan said that using the buffer's
> encoding is wrong, see:
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg01381.html
> 
> Stefan wanted to use the equivalent of emacs-mule for Emacs 23 instead
> of buffer's encoding, but do we have such an encoding now?  Is
> no-conversion-multibyte it?  Or maybe utf-8 is good enough?
> 
> But first, we should decide whether we want such buffers to compare
> equal or not.
> 
> 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?

I don't have much of an opinion because of ignorance in this area. If you are
asking whether ediff should treat buffers as different when they differ only by
encoding or line endings, I'd say probably yes and know: It would be good to
give the user all knowledge that ediff has, and then let the user control how to
compare. A message could let the user know about line-ending differences, for
example, and ask if you want to compare using only Emacs's internal encoding (or
whatever the correct terminology is) - that is, ignoring just the line-ending
difference.

IOW, give the user the knowledge and control. What's unacceptable is for Emacs
to throw up its hands and just say the two are different, without saying/showing
how they differ. The user should be able to drill down and see all possible
differences, perhaps showing different kinds of differences in different ways.

I'll leave the rest to you guys who know about this stuff. You get the drift of
what's missing/wrong. Thx.