From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.devel Subject: Re: Possible UTF-8 CJK Regressions in Terminal Emulators Date: Thu, 18 Mar 2004 15:34:07 +0000 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <1077557604.1632.26.camel@duende> <1077643915.12919.2.camel@duende> <1077682436.28482.9.camel@duende> <200403010815.RAA14365@etlken.m17n.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1079627272 10329 80.91.224.253 (18 Mar 2004 16:27:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 18 Mar 2004 16:27:52 +0000 (UTC) Cc: mariano@gnome.org, alexander.winston@comcast.net, emacs-devel@gnu.org, danilo@gnome.org, monnier@iro.umontreal.ca, miles@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Mar 18 17:27:45 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B40Mz-0002PL-00 for ; Thu, 18 Mar 2004 17:27:45 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B40My-0003lj-00 for ; Thu, 18 Mar 2004 17:27:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B40L7-0007Tc-R9 for emacs-devel@quimby.gnus.org; Thu, 18 Mar 2004 11:25:49 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B40K7-0007MH-KK for emacs-devel@gnu.org; Thu, 18 Mar 2004 11:24:47 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B3zgF-0006hV-1G for emacs-devel@gnu.org; Thu, 18 Mar 2004 10:44:06 -0500 Original-Received: from [148.79.80.39] (helo=albion.dl.ac.uk) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B3zXG-0003ol-D3; Thu, 18 Mar 2004 10:34:18 -0500 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 1B3zX5-0007QX-00; Thu, 18 Mar 2004 15:34:07 +0000 Original-To: Kenichi Handa User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:20584 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20584 [I don't know what this has to do with the subject.] Kenichi Handa writes: > In article , Miles Bader writes: > >> Alexander Winston writes: >>> Okay, back to UTF-8. With regard to CJK being disabled to default, I >>> believe that this decision is rather prejudicial to many Asian users. I don't think so. There's no reason why you shouldn't define a language environment corresponding to ja_JP.UTF-8 which turned it on (not that language environments is the right approach to locale handling). Anyway, there seems to be very little interest from users; I don't recall any of the contributions I expected. Mostly I've just had unhelpful remarks from non-CJK users. >> I've been told that the reason `utf-translate-cjk-mode' is disabled by >> default is that it consumes some non-trivial amount of memory (and >> loading time, Yes. If I remember correctly, I posted measurements. >> unless it's dumped I guess). It doesn't make sense to dump it, the way it works. > As we have post-read-conversion function for utf-8, it is > possible to detect untranslated CJK characters and translate > them. > > How abut this? > > Change utf-translate-cjk-mode to a customizable variable > utf-translate-cjk which is nil, t, or auto (default). The > values nil and t mean the same thing as the current value of > utf-translate-cjk-mode. The value `auto' means setting up > tables for translating CJK characters automatically if > necessary. > > By adding pre-write-conversion function, we can make the > above work also on writing. But, in that case, it seems > difficult to make find-coding-systems-region/string work > consistently. To check if a text is encodable by utf-8, we > must load translation tables. As far as I remember, that's why I didn't implement that sort of thing. post-read-conversion machinery is already there, I think. [Is this code base ever going to be released so that most users actually can use it?]