GNU bug report logs -
#23595
25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
Previous Next
Reported by: Uwe Brauer <oub <at> mat.ucm.es>
Date: Sat, 21 May 2016 13:03:01 UTC
Severity: normal
Found in version 25.1.50
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
Full log
Message #62 received at 23595 <at> debbugs.gnu.org (full text, mbox):
> Cc: oub <at> mat.ucm.es, 23595 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> 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.
This bug report was last modified 9 years and 24 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.