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: Stefan Monnier
Subject: bug#1183: 23.0.60; ediff-buffers is broken
Date: Sat, 18 Oct 2008 22:17:06 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

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







reply via email to

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