Re: ediff and coding systems

[kifer@cs.sunysb.edu (Michael Kifer)]

> In article <200710211922.l9LJMQFX013338@oogie-boogie.ics.uci.edu>, Dan Nicolaescu <dann@ics.uci.edu> writes:
> 
> > Can anybody else reproduce it? I don't know much about coding systems,
> > so unfortunately I can't really debug this myself.
> 
> I can reproduce it when I run Emacs with LANG=C, and try to
> see the 5th (or 6th) different point where non-ASCII
> charaters exist.  The calling sequence of read-coding-system
> is this:
> 
>   read-coding-system("Select coding system (default mule-utf-8): " mule-utf-8)
>   select-safe-coding-system-interactively(1 5557 (utf-8 ....))
>   select-safe-coding-system(1 5557 nil nil "/tmp/fineDiffA155544eB")
>   write-region(1 5557 "/tmp/fineDiffA155544eB" nil no-message)
>   ediff-make-temp-file(#<buffer  *ediff-tmp*> "fineDiffA" "/tmp/fineDiffA155544eB")
>   ediff-make-fine-diffs(5 noforce)
>   ediff-install-fine-diff-if-necessary(5)
>   ediff-next-difference(1)
>   call-interactively(ediff-next-difference)
> 
> I don't know why ediff-make-temp-file is called, but perhaps
> it should call write-region while binding
> coding-system-for-write to `no-conversion' or `emacs-mule'.

I still cannot reproduce this, but ediff-make-temp-file has been changed on
Aug 19 to use the coding system of the buffer for the temp file created out
of that buffer. This was in order to fix some other problem. Forgot which
-- it was on this list. The coding system of the buffer seems to be the
right thing. It was 'no-conversion before, but had a problem because those
temp files are then read back and no-conversion was screwing things up.




> 
> ---
> Kenichi Handa
> handa@m17n.org
>