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

From: Paul Eggert <[email-masked]>
Date: Tue, 24 May 2016 23:19:01 -0700

Eli Zaretskii wrote:
> What Emacs should do is
> bind coding-system-for-read to utf-8 in this case (not leave it
> unbound as in your patch), under the assumption that the user used the
> procedure outlined by Paul.

I don't see how this would work for files like etc/HELLO, which use iso-2022-jp. 
But perhaps the above comment is obsolete 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.

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.

> testing this at run time sounds like waste of cycles.

Not so many cycles that anyone will really care, I expect.

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.