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: display table for eight-bit-graphic Date: Wed, 29 Jan 2003 20:03:07 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200301291103.UAA17535@etlken.m17n.org> References: <200301270220.LAA14193@etlken.m17n.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1043838151 27452 80.91.224.249 (29 Jan 2003 11:02:31 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 29 Jan 2003 11:02:31 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18dpzB-00078c-00 for ; Wed, 29 Jan 2003 12:02:29 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18dq4J-0004rA-00 for ; Wed, 29 Jan 2003 12:07:47 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18dq0F-0002Tp-02 for emacs-devel@quimby.gnus.org; Wed, 29 Jan 2003 06:03:35 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18dpzu-0002Rd-00 for emacs-devel@gnu.org; Wed, 29 Jan 2003 06:03:14 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18dpzs-0002R3-00 for emacs-devel@gnu.org; Wed, 29 Jan 2003 06:03:13 -0500 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18dpzr-0002QN-00; Wed, 29 Jan 2003 06:03:12 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])h0TB38k22008; Wed, 29 Jan 2003 20:03:08 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) h0TB38R03175; Wed, 29 Jan 2003 20:03:08 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id UAA17535; Wed, 29 Jan 2003 20:03:07 +0900 (JST) Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Tue, 28 Jan 2003 19:04:09 -0500) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) Original-cc: d.love@dl.ac.uk X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:11187 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11187 In article , Richard Stallman writes: >> This way, people who don't like MULE and use Emacs in unibyte >> mode with European character sets get the same behavior as before. > I don't think so. See this comment again: > ;; If default-enable-multibyte-characters is nil, > ;; we are using single-byte characters, > ;; so the display table and terminal coding system are irrelevant. > Where is that comment? It's in the function set-locale-environment (in mule-cmds.el). > (when default-enable-multibyte-characters > (set-display-table-and-terminal-coding-system language-name)) > It seesm that the intention is to use the display table for > multibyte buffers. > It is definitely intended to use the display table for multibyte > buffers--but I think that's not actually the issue you are talking > about. I'm talking that using the display table in multibyte session is not good. > Anyway, I don't think this actually contradicts anything I said. > The display table is used for unibyte buffers, too. If we > want unibyte buffers to display the international graphics, > we have to set up the display table for codes 128-255. We don't have to use the display table even for unibyte buffers. Even for a unibyte buffer, get_next_display_element in xdisp.c doesn't generate a octal form "\XXX" for a code in the range 128-255 if the code can be converted to a multibyte character by unibyte_char_to_multibyte. So, such a code is given to x_produce_glyph as is. Then, in x_produce_glyph, if unibyte-display-via-language-environment is nil, that code is used as is (thus is displayed by the default font), otherwise, that code is converted to a multibyte char (thus is displayed by a font selected from the current fontset). In short, both in multibyte and unibyte sesseion, there's no need of setting the display table now. --- Ken'ichi HANDA handa@m17n.org