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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: kifer <at> cs.sunysb.edu, handa <at> m17n.org, drew.adams <at> oracle.com,
        1183 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org,
        kifer <at> cs.stonybrook.edu
Subject: bug#1183: 23.0.60; ediff-buffers is broken
Date: Sat, 18 Oct 2008 22:17:06 -0400

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

Indeed.  This encoding is now also available under the new name
`emacs-internal'. [ As you may have seen, I also added it to the
Emacs-22 branch, although I doubt we'll release anything from that
branch. ]

> The problem with that is that ediff-exec-process then uses raw-text to
> read the output from Diff back into Emacs.

Yes, raw-text is wrong.  It should probably use undecided at least, or
otherwise try to be more clever and use the encoding used by the
source files.

> While raw-text is probably OK for reading Diff output from comparing
> _files_,

There's worse, but for Unicode files (or for latin-1 files, or for ...)
it's kind of ugly.  I suspect that for utf-16 and Chinese it's
even worse.

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

Yes, that's part of the problem.

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

Actually, after looking at it a little bit, there are some reasons: the
encoding is currently set in ediff-make-temp-file which is used in many
different circumstances, some of which should use emacs-internal, but
maybe not all.  So there's more work to do in ediff to handle
encoding issues reliably.


        Stefan

Previous Next

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