From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: display table for eight-bit-graphic Date: Fri, 21 Mar 2003 14:07:59 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200301270220.LAA14193@etlken.m17n.org> <200303191058.TAA29732@etlken.m17n.org> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1048274258 15880 80.91.224.249 (21 Mar 2003 19:17:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 21 Mar 2003 19:17:38 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Mar 21 20:17:37 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 18wS0v-00045r-00 for ; Fri, 21 Mar 2003 20:17:13 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18wS2m-0003n5-00 for ; Fri, 21 Mar 2003 20:19:08 +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 18wRzO-0007fi-00 for emacs-devel@quimby.gnus.org; Fri, 21 Mar 2003 14:15:38 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18wRyq-0007A0-00 for emacs-devel@gnu.org; Fri, 21 Mar 2003 14:15:04 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18wRyW-0006XR-00 for emacs-devel@gnu.org; Fri, 21 Mar 2003 14:14:45 -0500 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.10.13) id 18wRrz-0003US-00 for emacs-devel@gnu.org; Fri, 21 Mar 2003 14:07:59 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.10) id 18wRrz-0005PX-00; Fri, 21 Mar 2003 14:07:59 -0500 Original-To: Kenichi Handa In-reply-to: <200303191058.TAA29732@etlken.m17n.org> (message from Kenichi Handa on Wed, 19 Mar 2003 19:58:57 +0900 (JST)) 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:12516 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12516 In unibyte buffer, by setting unibyte-display-via-language-environment to non-nil, 8-bit characters are converted to multibyte characters by unibyte-char-to-multibyte on displaying. The merit of this is that when a user changes the language environment, 8-bit characters are displayed correctly based on the current language environment. That is a sensible feature, but it isn't an exact replacement for the current features that use the display table, such as set-language-environment in unibyte mode. It uses set-display-table-and-terminal-coding-system. It's possible that the unibyte-display-via-language-environment feature does mostly the same thing as set-display-table-and-terminal-coding-system, but that also sets up the display table for code 146. If it calls standard-display-european-internal, that also sets the display table for code 160. If you can make unibyte-display-via-language-environment handle codes 146 and 160 in these ways, then perhaps it would be an exact replacement for the current feature. I am not sure. I am also unsure whether that change would have some other drawback.