[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: Paul Eggert
Subject: bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
Date: Mon, 23 May 2016 15:16:56 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0

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.

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.

diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index 25b41e3..b62b68d 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -1696,6 +1696,8 @@ vc-diff-internal
     (setq coding-system-for-read
           (coding-system-change-eol-conversion coding-system-for-read
+ (unless (coding-system-get coding-system-for-read :ascii-compatible-p) + (setq coding-system-for-read nil))

reply via email to

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