bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#1183: 23.0.60; ediff-buffers is broken


From: Eli Zaretskii
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@gnu.org>
> Cc: 1183@emacsbugs.donarmstrong.com, bug-gnu-emacs@gnu.org,
>       emacs-pretest-bug@gnu.org
> 
> > From: "Drew Adams" <drew.adams@oracle.com>
> > Cc: <emacs-pretest-bug@gnu.org>, <bug-gnu-emacs@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?







reply via email to

[Prev in Thread] Current Thread [Next in Thread]