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

Previous Next

Full log

Message #80 received at 23595 <at> debbugs.gnu.org (full text, mbox):

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

Eli Zaretskii wrote:
> What Emacs should do is
> bind coding-system-for-read to utf-8 in this case (not leave it
> unbound as in your patch), under the assumption that the user used the
> procedure outlined by Paul.

I don't see how this would work for files like etc/HELLO, which use iso-2022-jp. 
But perhaps the above comment is obsolete 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.

Better, but this wouldn't work for coding systems like ebcdic-us, which are so 
incompatible with ASCII that messages like "Binary files differ" would turn into 
gibberish.

> testing this at run time sounds like waste of cycles.

Not so many cycles that anyone will really care, I expect.

We could establish a new coding system property for "close enough to ASCII that 
most people won't mind". That would be a more-intrusive change, though. For 
emacs-25 I thought it'd be better to have something that is more self-contained.

Previous Next

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