From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: bidi properties from uniprop tables Date: Fri, 19 Aug 2011 18:15:58 +0900 Message-ID: <87fwkxlq29.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83ei0isfok.fsf@gnu.org> <87k4aako1r.fsf@uwakimon.sk.tsukuba.ac.jp> <83aab5sxy0.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1313745368 389 80.91.229.12 (19 Aug 2011 09:16:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 19 Aug 2011 09:16:08 +0000 (UTC) Cc: handa@m17n.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 19 11:16:03 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QuLBG-0000EO-Sj for ged-emacs-devel@m.gmane.org; Fri, 19 Aug 2011 11:15:59 +0200 Original-Received: from localhost ([::1]:58259 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QuLBG-0003pW-Bx for ged-emacs-devel@m.gmane.org; Fri, 19 Aug 2011 05:15:58 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:40896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QuLBD-0003p4-Ow for emacs-devel@gnu.org; Fri, 19 Aug 2011 05:15:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QuLBC-00015W-S4 for emacs-devel@gnu.org; Fri, 19 Aug 2011 05:15:55 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:33368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QuLBB-00013z-32; Fri, 19 Aug 2011 05:15:53 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 0A6143FA070F; Fri, 19 Aug 2011 18:15:50 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 396C11A330B; Fri, 19 Aug 2011 18:15:59 +0900 (JST) In-Reply-To: <83aab5sxy0.fsf@gnu.org> X-Mailer: VM 8.1.93a under 21.5 (beta31) "ginger" cd1f8c4e81cd XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.223 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:143431 Archived-At: Eli Zaretskii writes: > > From: "Stephen J. Turnbull" > > Cc: Kenichi Handa , > > emacs-devel@gnu.org > > Date: Fri, 19 Aug 2011 13:44:48 +0900 > > > > > I made the code in bidi.c defensive about what it gets from the > > > > Maybe that should be an assert, since a null return is an Emacs bug. > > There's already something that catches such problems, albeit > indirectly, and aborts -- that's how I found this in the first place. > However, it doesn't make sense to have an assert where the bidi > property of a character is looked up as long as we don't make sure > this doesn't happen "normally", The point was to make sure that this doesn't happen normally, as my understanding was that this is an Emacs bug. > because having such an assert now will cause a predictable crash > when moving in a buffer created by describe-categories. People use > the development version for their day-to-day work, you know... Of course I know that; I run with asserts enabled in several of my mission-critical applications (but save early and often, and have a stable version ready to substitute). Doesn't everybody? So obviously you fix the bug first, then add the assert. > > > uniprop table, but the question is, should we do something to never > > > have nil in Lisp or zero in C return from these APIs? > > > > Yes, a non-nil property list is required by the standard for all code > > points > > It's not a property list, it's a single property whose value is a > symbol that shouldn't be nil. See get-char-code-property. Then no, you shouldn't do that for all properties, because not all properties are defined for all characters. Given that this is Lisp, it should be possible to discover that from the value returned. Some properties, however, are defined for all code points. If the properties in question are defined for all code points or all characters (presumably Emacs should never allow a non-character code point in a string or buffer?), then it's an Emacs bug in get-char-code-property (or in the underlying table) if it returns nil. If they aren't, then IMO it's a bug in the calling code that it's not prepared for a null return, and your "defensive code" in bidi.c is a correct bug fix. With respect to the Bidi_Class property, UAX#9 says: Unassigned characters are given strong types in the algorithm. This is an explicit exception to the general Unicode conformance requirements with respect to unassigned characters. As characters become assigned in the future, these bidirectional types may change. For assignments to character types, see DerivedBidiClass.txt [DerivedBIDI] in the [UCD]. Since Bidi_Class is only used in this algorithm (and explicit property lookups) AFAIK, it seems reasonable to me that get-char-code-property et amis should return the "strong type" specified by DerivedBIDI (which is LTR it seems, but you should check that).