GNU bug report logs - #1183
23.0.60; ediff-buffers is broken

Previous Next

Package: emacs;

Reported by: "Drew Adams" <drew.adams <at> oracle.com>

Date: Thu, 16 Oct 2008 18:55:03 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: 1183 <at> debbugs.gnu.org
Cc: drew.adams <at> oracle.com, bug-gnu-emacs <at> gnu.org,
        Michael Kifer <kifer <at> cs.stonybrook.edu>
Subject: bug#1183: 23.0.60; ediff-buffers is broken
Date: Fri, 17 Oct 2008 14:38:46 +0200
> Date: Thu, 16 Oct 2008 23:15:45 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 1183 <at> emacsbugs.donarmstrong.com, bug-gnu-emacs <at> gnu.org,
> 	emacs-pretest-bug <at> gnu.org
> 
> > From: "Drew Adams" <drew.adams <at> oracle.com>
> > Cc: <emacs-pretest-bug <at> gnu.org>, <bug-gnu-emacs <at> gnu.org>
> > Date: Thu, 16 Oct 2008 13:45:21 -0700
> > 
> > > 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?




This bug report was last modified 16 years and 218 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.