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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: oub@mat.ucm.es, 23595@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 23 May 2016 15:16:56 -0700
> 
> On 05/23/2016 02:02 PM, Dmitry Gutov wrote:
> > Not sure what's the best place to do it, but the patch below gives me 
> > 24.5's behavior (correctly decoding the short "Binary files ... 
> > differ" output). Could someone try it together with Paul's solution?
> >
> 
> 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. 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.

For some reason I don't quite understand, iso-2022-jp fails the
ascii-compatible-p test.  We could make an exception for the iso-202
family in this case.  Then the bug would not creep back in.

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

Yes, but we know in advance which coding-systems will be unable to do
that, so testing this at run time sounds like waste of cycles.