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: Eli Zaretskii <eliz <at> gnu.org>
To: eggert <at> cs.ucla.edu
Cc: oub <at> mat.ucm.es, 23595 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
Date: Tue, 24 May 2016 18:36:59 +0300

> Date: Tue, 24 May 2016 05:40:44 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: oub <at> mat.ucm.es, dgutov <at> yandex.ru, 23595 <at> debbugs.gnu.org
> 
> > 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.

OK, I understand that now.  ascii-compatible-p is not the right test,
the right one is mime-text-unsuitable-p; and the test should be
reversed, i.e. this:

  (coding-system-get CODING-SYSTEM :mime-text-unsuitable-p)

should return nil for CODING-SYSTEM to be usable.

Previous Next

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