bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)

[Dmitry Gutov]

On 05/24/2016 01:16 AM, Paul Eggert wrote:

> It worked for me in the Bug#23595 test case, with Git configured with
> utf16<->utf8 filters as I described. However, it reintroduces a bug when
> the version-controlled uses ISO-2022-JP.

Does it have a bug report? Can we have a test case?

> If I make a trivial change to
> etc/HELLO, for example, the patch can cause vc-diff to display mojibake,
> as the output of "git diff" uses ISO0-2022-JP but vc-diff decodes it as
> UTF-8. Although this is the same mojibake that Emacs 24.5 generates so
> the behavior is not a regression from 24.5, it is a regression from
> current emacs-25.

That's too bad.

> We are on thin ice here no matter what. One idea to improve on the
> current emacs-25 behavior is to test whether a simple ASCII message like
> "Binary files differ" encodes as itself using the file's coding system,
> and to use the file's coding system if it does and locale-coding-system
> if it doesn't.

How would we do that? We're currently picking conding-system-for-read 
well before the first byte of the output is generated.