From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: [harder@ifa.au.dk: `set-locale-environment' bug] Date: Wed, 12 Nov 2003 11:40:15 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200311120240.LAA02931@etlken.m17n.org> References: <200310280714.QAA05836@etlken.m17n.org> <200311100236.LAA28922@etlken.m17n.org> <9743-Mon10Nov2003073149+0200-eliz@elta.co.il> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1068605487 2588 80.91.224.253 (12 Nov 2003 02:51:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 12 Nov 2003 02:51:27 +0000 (UTC) Cc: harder@ifa.au.dk, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Nov 12 03:51:23 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AJl6J-0003Du-00 for ; Wed, 12 Nov 2003 03:51:23 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AJl6I-0002Rn-01 for ; Wed, 12 Nov 2003 03:51:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AJly2-0007U2-85 for emacs-devel@quimby.gnus.org; Tue, 11 Nov 2003 22:46:54 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AJltg-0006El-KM for emacs-devel@gnu.org; Tue, 11 Nov 2003 22:42:24 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AJltA-00065l-5I for emacs-devel@gnu.org; Tue, 11 Nov 2003 22:42:23 -0500 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AJlt9-00064Z-0i for emacs-devel@gnu.org; Tue, 11 Nov 2003 22:41:51 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6p2/3.7W-20010518204228) with ESMTP id hAC2eGh17505; Wed, 12 Nov 2003 11:40:16 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6/3.7W-20010823150639) with ESMTP id hAC2eGs00459; Wed, 12 Nov 2003 11:40:16 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id LAA02931; Wed, 12 Nov 2003 11:40:15 +0900 (JST) Original-To: eliz@elta.co.il In-reply-to: <9743-Mon10Nov2003073149+0200-eliz@elta.co.il> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 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:17773 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17773 In article <9743-Mon10Nov2003073149+0200-eliz@elta.co.il>, "Eli Zaretskii" writes: >> But, in multibyte-mode, it seems that only MS-DOS case (on >> terminal) really requires standard-display-table to be >> setup. That is because, in that case, characters in the >> current codepage that are not supported by Emacs are decoded >> into eight-bit-control/graphic, and they must be displayed >> by the font of the current codepage as is. >> >> Eli, is that right? > Yes and no. > No, because unsupported characters are not displayed as the current > codepage's glyphs, they are displayed as a special glyph whose value > is in `dos-unsupported-char-glyph'. > Yes, because term/internal.el, the MS-DOS ``internal terminal'' > emulator, sets up standard-display-table to display non-ASCII > characters beyond the current codepage, such as Latin-2 for a cp-850 > locale, as strings of ASCII characters, see IT-display-table-setup. Thank you for the explanation. It seems that all settings about display table and terminal coding system is done by dos-codepage-setup via term-setup-hook. So, mule-cmds.el should do nothing for them on DOS, right? > I think in the past standard-display-table was used on multibyte > sessions on Unix as well, to map some characters originating from > Microsoft's codepages to printable ASCII chars, but I'm not sure > whether I remember correctly and if so, why was that removed. I think we must think over making the code in mule-cmds clearer now. The current code is quite confusing and it seems that there are bugs. For instance, at starup time, set-display-table-and-terminal-coding-system is called in this way now: command-line -> set-local-environment -> set-language-environment -> set-display-table-and-terminal-coding-system (in unibyte mode only) -> set-display-table-and-terminal-coding-system (in multibyte mode only) And set-display-table-and-terminal-coding-system calls standard-display-european-internal in a lang. env. that has `unibyte-display' setting, and resets standard-display-table for 8-bit chars otherwise. So, for instance, if we start in some European locale in multibyte mode, standard-display-european-internal is called, but when we switch to Japanese lang. env., the standard-display-table is not reset. On the other hand, if we start in Japanese locale in multibyte mode, even if we switch to some European locale, standard-display-european-internal is not called. But I need more time to study the current code to give a concrete proposal for solving it. --- Ken'ichi HANDA handa@m17n.org