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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Eli Zaretskii <eliz <at> gnu.org>
Cc: oub <at> mat.ucm.es, 23595 <at> debbugs.gnu.org
Subject: bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
Date: Tue, 24 May 2016 01:28:58 +0300

On 05/24/2016 01:16 AM, Paul Eggert wrote:

> 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.

Does it have a bug report? Can we have a test case?

> 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.

That's too bad.

> 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.

How would we do that? We're currently picking conding-system-for-read 
well before the first byte of the output is generated.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.