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

[Eli Zaretskii]

> Cc: oub@mat.ucm.es, 23595@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 24 May 2016 23:19:01 -0700
> 
>     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.
> 
> Better, but this wouldn't work for coding systems like ebcdic-us, which are 
> so incompatible with ASCII that messages like "Binary files differ" would 
> turn into gibberish. 

It's easy enough to exempt EBCDIC (and any other similar encodings).
There are only 3 of them, AFAICS.

> We could establish a new coding system property for "close enough to ASCII 
> that most people won't mind". That would be a more-intrusive change, though. 
> For emacs-25 I thought it'd be better to have something that is more 
> self-contained. 

A :mime-text-unsuitable-p test augmented by a list of additional
coding-systems we find unsuitable is simple, self-contained, and safe
for emacs-25, IMO.  For master, we could add a cleaner, but more
intrusive fix.