From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM Date: Mon, 29 Nov 2010 15:35:04 +0900 Message-ID: References: <83bp5te3s8.fsf@gnu.org> <834obfd9iy.fsf@gnu.org> <83wrnz5fac.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1291012532 19976 80.91.229.12 (29 Nov 2010 06:35:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 29 Nov 2010 06:35:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 29 07:35:25 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PMxKe-0001DT-Go for ged-emacs-devel@m.gmane.org; Mon, 29 Nov 2010 07:35:24 +0100 Original-Received: from localhost ([127.0.0.1]:52266 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PMxKd-00008q-Nk for ged-emacs-devel@m.gmane.org; Mon, 29 Nov 2010 01:35:23 -0500 Original-Received: from [140.186.70.92] (port=50068 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PMxKR-000085-Ta for emacs-devel@gnu.org; Mon, 29 Nov 2010 01:35:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PMxKQ-00054e-Uj for emacs-devel@gnu.org; Mon, 29 Nov 2010 01:35:11 -0500 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:64224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PMxKO-000533-Lv; Mon, 29 Nov 2010 01:35:09 -0500 Original-Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id oAT6Z5dt021084; Mon, 29 Nov 2010 15:35:05 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id oAT6Z49Z016749; Mon, 29 Nov 2010 15:35:05 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp3.aist.go.jp with ESMTP id oAT6Z402016064; Mon, 29 Nov 2010 15:35:04 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.71) (envelope-from ) id 1PMxKK-0008Us-AP; Mon, 29 Nov 2010 15:35:04 +0900 In-Reply-To: <83wrnz5fac.fsf@gnu.org> (message from Eli Zaretskii on Sat, 27 Nov 2010 10:42:03 +0200) X-detected-operating-system: by eggs.gnu.org: Solaris 9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133221 Archived-At: In article <83wrnz5fac.fsf@gnu.org>, Eli Zaretskii writes: > > But, as I wrote before, I'm still hesitating over which is > > better; keeping glyphless-char-display separate from display > > table, or integrating that functionality to display table. > What are the pros and cons, which make you hesitate? Both glyphless-char-display and display table control the displaying of each character. I think such a control should be done by a single mechanism. At least it will benefit users in a long run. But, the biggest concern is about the backward compatibility. Currently, a display table element is nil or vector of characters. If there's a code that assumes that a non-nil element is a vector of characters, it will be broken. Next, a display table is not inherited. So, if buffer-display-table or a window-specific display is set, standard-display-table is not looked up. At last, there are several standard-display-XXX functions (e.g. standard-display-8bit). At the moment, I don't know how to make the functionality of glyphless-char-display-control go with them. > > I agree on exempting TAB and NL from c0-control group. > Done. Thank you. --- Kenichi Handa handa@m17n.org