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
View this message in rfc822 format
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
> 'dos)))
> + (unless (coding-system-get coding-system-for-read
> :ascii-compatible-p)
> + (setq coding-system-for-read nil))
This bug report was last modified 9 years and 23 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.