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: Tue, 18 Mar 2003 16:26:18 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200303180726.QAA28116@etlken.m17n.org> References: <200301270220.LAA14193@etlken.m17n.org> <200301291103.UAA17535@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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1047972499 23015 80.91.224.249 (18 Mar 2003 07:28:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 18 Mar 2003 07:28:19 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Mar 18 08:28:17 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18vBVn-0005yJ-00 for ; Tue, 18 Mar 2003 08:27:51 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18vBVx-0006HT-00 for ; Tue, 18 Mar 2003 08:28:01 +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 18vBUh-00030M-04 for emacs-devel@quimby.gnus.org; Tue, 18 Mar 2003 02:26:43 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18vBUN-0002uB-00 for emacs-devel@gnu.org; Tue, 18 Mar 2003 02:26:23 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18vBUM-0002ts-00 for emacs-devel@gnu.org; Tue, 18 Mar 2003 02:26:23 -0500 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18vBUL-0002rA-00; Tue, 18 Mar 2003 02:26:22 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])h2I7QI915490; Tue, 18 Mar 2003 16:26:18 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) h2I7QIA02092; Tue, 18 Mar 2003 16:26:18 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id QAA28116; Tue, 18 Mar 2003 16:26:18 +0900 (JST) Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Mon, 03 Mar 2003 13:59:49 -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:12432 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12432 Sorry for the late reply on this matter. In article , Richard Stallman writes: >> 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. > It sounds like you're suggesting that we eliminate the display > table feature. No. The display table is useful even in a multibyte buffer if Emacs is running on a terminal like the case of MSDOS. For instance, if one is using a terminal that can display only ASCII, he may want to setup the display table so that, for instance, `=C0' (A-grave) is displayed as "A`". > Perhaps the display table is obsolete as a means of displaying > non-ASCII characters, assuming we set up for proper conversion > to unibyte according to the language in use. =20 I think the display table is obsolete only as a means of displaying 8-bit characaters in unibyte buffer and eight-bit-control/graphic characters. At least in the latter case, they should be displayed by octal-form by default. --- Ken'ichi HANDA handa@m17n.org