|
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.
[Prev in Thread] | Current Thread | [Next in Thread] |