[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]