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: Mon, 27 Jan 2003 11:20:00 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200301270220.LAA14193@etlken.m17n.org> References: 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 1043634458 21875 80.91.224.249 (27 Jan 2003 02:27:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 27 Jan 2003 02:27:38 +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 18cyzp-0005gf-00 for ; Mon, 27 Jan 2003 03:27:37 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18cz3o-0006RR-00 for ; Mon, 27 Jan 2003 03:31:44 +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 18cz09-0007y4-01 for emacs-devel@quimby.gnus.org; Sun, 26 Jan 2003 21:27:57 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18cyzd-0007kv-00 for emacs-devel@gnu.org; Sun, 26 Jan 2003 21:27:25 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18cyyi-0007NQ-00 for emacs-devel@gnu.org; Sun, 26 Jan 2003 21:26:44 -0500 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18cysq-0006BH-00; Sun, 26 Jan 2003 21:20:24 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])h0R2K1k12655; Mon, 27 Jan 2003 11:20:01 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) h0R2K1R16698; Mon, 27 Jan 2003 11:20:01 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id LAA14193; Mon, 27 Jan 2003 11:20:00 +0900 (JST) Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Sun, 26 Jan 2003 10:37:15 -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:11103 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11103 In article , Richard Stallman writes: > But, I've just found that standard-display-table is setup > when we start Emacs with any locale of single byte charset > (e.g. iso-8859-1). It seems that it is done intentionally > by set-locale-environment as below. > The reason for this is probably for the sake of unibyte buffers. > 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. (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. > In the past, this code only affected unibyte buffers because those > character codes 128-255 normally only appeared in them. But nowadays, > all those codes are normal in multibyte buffers too. The display > table treats each code the same way regardless of whether it comes > from a unibyte buffer or a multibyte buffer. Yes. I don't object to the currently behaviour of display table itself. If one really wants to see eight-bit-control/graphic chars in a multibyte buffer by some glyph, it's ok to use display table as he wishes. What I object is to setting up the display table as now by default. kai.grossjohann@uni-duisburg.de (Kai Gro=DFjohann) writes: > "Ehud Karni" writes: >> I agree. For persons in the ISO-8859-x languages, the 8 bit graphics >> is much better than the octal representation. > I do not agree that displaying the graphics is better. > It might seem so at first sight, but there are problems later on: for > instance, you can't search for the 8bit graphics characters by typing > Latin-1 characters, and people will surely be *very* surprised that > they can't find their characters! I agree with that. Showing different characters by the same glyph is the source of confusion at least for novice users. First of all, 8-bit characters should not appear in a multibyte buffer usually. It it does, mainly it's because of a bug of some program, on in a case that it should be treated as raw bytes, not as characters. In both cases, it is better that they are not displayed as graphics. > Maybe it would be useful to highlight the graphics characters in some > way so that it is clear that they aren't normal characters. I'm not sure that is a good idea. Highlighting means many things. Octal displaying is far better to indicate that they aren't normal characters. --- Ken'ichi HANDA handa@m17n.org