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

[Eli Zaretskii]

> Date: Tue, 24 May 2016 05:40:44 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: oub@mat.ucm.es, dgutov@yandex.ru, 23595@debbugs.gnu.org
> 
> > 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.

OK, I understand that now.  ascii-compatible-p is not the right test,
the right one is mime-text-unsuitable-p; and the test should be
reversed, i.e. this:

  (coding-system-get CODING-SYSTEM :mime-text-unsuitable-p)

should return nil for CODING-SYSTEM to be usable.