Re: idn.el and confusables.txt

[handa]

In article <address@hidden>, Eli Zaretskii <address@hidden> writes:

> Are functions defined by ucs-normalize.el used anywhere?

What do you mean by "anywhere".  That file provides a coding
system utf-8-hfs that uses functions in that file.  And I
don't know whether a specific coding system is used or not
except for what I use.  In addition, I have a plan of using
the facility of normalization to display, for instance, the
sequence 'A' '́' by 'Á' when a font doesn't support OTF GPOS
features.

> > Why did you have to create another table?  Was it because
> > get-char-code-property is defiend by Lisp and not efficient
> > to call from C?

> Yes, calling a Lisp function (one that calls `load' at that!) in the
> lowest level of display engine was out of the question.

Why?  If that loading is just once, what's the problem?  For
automatic composition, we are already doing that.

> But there were several other reasons as well:

>   . get-char-code-property returns a property list in which bidi types
>     are recorded as symbols, while I needed them as small numeric
>     values of a C enumerated type (see bidi_type_t), to fit in a small
>     number of bits in `struct glyph'.

>   . The data structures manipulated by get-char-code-property include
>     complications (e.g., a function in the extra slot) for which I
>     could find no documentation, so I couldn't figure out whether it
>     would be possible to replace get-char-code-property by a simple
>     call to CHAR_TABLE_REF.

>   . Even if I could use CHAR_TABLE_REF, the additional call to
>     plist-get means more overhead.  bidi_get_type, the function which
>     needs to look up the bidirectional type of an arbitrary character,
>     runs in the innermost loop of the display engine, and is called at
>     least once (sometimes more) for every character in the displayed
>     portion of the buffer, so it must be very efficient.

>   . For bidi-mirrored property, the data in the `mirrored' property
>     recorded by uni-mirrored.el is simply inadequate: the value is a
>     boolean (albeit in a form of symbols `Y' and `N').  What I needed
>     was for each character its mirrored character, if there is one;
>     this data was simply not available in uni-mirrored.el.  The
>     corresponding function bidi_mirror_char is also called for a large
>     percentage of displayed characters, and must be efficient.

> It was extremely frustrating to have all that data at my fingertips
> and not be able to use it for the purposes of bidi.c, which at first
> seems like a first-class client of Unicode DB.  What I wanted was
> something similar to C ctype macros in simplicity and efficiency, but
> nothing quite like that was available.  A char-table comes close, but
> it must be a simple table with numerical values -- and that is what
> bidi.c currently uses, leaving uni-bidi.el unused.

I understand your situation, and it's unfortunate that you
didn't consult me to improve the situation.  I think it's
not difficult to write a C code that makes uni-* char-tables
more easily be accessed from C without running Lisp.

As for the value type of symbol vs integer in uni-bidi.el,
it's possible to write a code to expose integer value to
C, and the corresponding symbol to Lisp.

As for the uni-mirrored.el, I think it's ok to change the
value type to what you want (character or nil).

---
Kenichi Handa
address@hidden