From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM Date: Mon, 29 Nov 2010 13:06:13 -0500 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 1291054004 23416 80.91.229.12 (29 Nov 2010 18:06:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 29 Nov 2010 18:06:44 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 29 19:06:37 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 1PN87U-0001n9-Ka for ged-emacs-devel@m.gmane.org; Mon, 29 Nov 2010 19:06:32 +0100 Original-Received: from localhost ([127.0.0.1]:49477 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PN87T-0001eq-Gk for ged-emacs-devel@m.gmane.org; Mon, 29 Nov 2010 13:06:31 -0500 Original-Received: from [140.186.70.92] (port=33210 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PN87J-0001d9-42 for emacs-devel@gnu.org; Mon, 29 Nov 2010 13:06:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PN87H-0005hY-LD for emacs-devel@gnu.org; Mon, 29 Nov 2010 13:06:20 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:59288) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PN87H-0005h7-Gz; Mon, 29 Nov 2010 13:06:19 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id oATI6Eqr004426; Mon, 29 Nov 2010 13:06:15 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 5C443A85E0; Mon, 29 Nov 2010 13:06:13 -0500 (EST) In-Reply-To: (Kenichi Handa's message of "Mon, 29 Nov 2010 15:35:04 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3694=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:133232 Archived-At: > 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. Agreed. > 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. Let's not worry about that case for now. Such code is probably rare and easy to fix. > 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. IIRC that's a bug in itself that should be fixed. > 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. Most of those functions are largely historical baggage whose precise meaning has evolved over time, so I think it's OK to change it yet a bit further (and to deprecate them more if needed). Stefan