emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using uniprop_table_lookup


From: Eli Zaretskii
Subject: Re: Using uniprop_table_lookup
Date: Mon, 15 Aug 2011 11:57:09 +0300

> From: Kenichi Handa <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Tue, 09 Aug 2011 13:31:00 +0900
> 
> In article <address@hidden>, Stefan Monnier <address@hidden> writes:
> > > No.  All returned tables by uniprop_table are stored in
> > > Vchar_code_property_alist which is DEFVAR_LISPed in
> > > chartab.c.  It means that the next call of uniprop_table
> > > with the same PROP argument just returns the already loaded
> > > one, and thus fast.
> 
> > But since Eli says that he initializes bidi_class_table only once and
> > never touches it again, if he doesn't staticpro that variable and
> > someone does someone changes Vchar_code_property_alist, you could end up
> > with bidi_class_table pointing to a dead object.
> 
> Ah, yes, you are right.  I misunderstood.

I have another question.  The commentary in chartab.c says:

   and get a property value for character CH as this:

       Lisp_Object bidi_class = CHAR_TABLE_REF (CH, bidi_class_table);

   In this case, what you actually get is an index number to the
   vector of property values (symbols nil, L, R, etc).

What does it mean by "in this case"? is this something specific to the
"bidi-class" property?  If yes, what will the call to CHAR_TABLE_REF
yield in the general case?  It is essential to document that, for the
C code to be able to use any Unicode character property through this
API.

The commentary also says:

   o The second extra slot is a Lisp function, an index (integer) to
   the array uniprop_decoder[], or nil.  If it is a Lisp function, we
   can't use such a table from C (at the moment).  If it is nil, it
   means that we don't have to decode values.

   o The third extra slot is a Lisp function, an index (integer) to
   the array uniprop_encoder[], or nil.  If it is a Lisp function, we
   can't use such a table from C (at the moment).  If it is nil, it
   means that we don't have to encode values.

This doesn't say anything about the indices into uniprop_decoder[] and
uniprop_encoder[] arrays, which I believe are values that need to be
handled by the C code.  Can you tell something about that?  I would
like to improve this commentary with the additional information.

TIA



reply via email to

[Prev in Thread] Current Thread [Next in Thread]