[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: Tue, 24 May 2016 23:19:01 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

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.

reply via email to

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