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, Paul Eggert <eggert@cs.ucla.edu>
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 24 May 2016 00:02:36 +0300
> 
> On 05/23/2016 07:48 PM, Eli Zaretskii wrote:
> 
> >>> The resulting diff contains either rubbish or fails to run.
> >>> Files attached.
> >
> > I don't see any rubbish in the Git output.
> 
> Might that have to do something with your OS? I see the mojibake like 
> others.

I was talking about the attachment Uwe provided, so this has nothing
to do with my OS.

> > As for the first problem, we should probably refrain from binding
> > coding-system-for-read to a CODING-SYSTEM for which
> >
> >    (coding-system-get CODING-SYSTEM :ascii-compatible-p)
> >
> > returns nil.  We should instead bind it to no-conversion and decode
> > the file data parts by hand, skipping the parts that Git itself
> > outputs (yes, this is messy).  Patches to that effect are welcome.
> 
> 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?

Paul's solution is outside of Emacs's realm.  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.