Re: idn.el and confusables.txt

[Eli Zaretskii <eliz@gnu.org>]

> From: handa <handa@m17n.org>
> Cc: monnier@iro.umontreal.ca, tzz@lifelogs.com, emacs-devel@gnu.org
> Date: Wed, 18 May 2011 14:23:26 +0900
> 
> > > 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.

When I started working on bidirectional support, I didn't know that
(as well as many other intimate details of the display engine I know
now).  Loading and calling Lisp code in the middle of redisplay buffer
iteration surely sounded scary.  I also didn't know then whether we
will enable the bidi reordering by default, or just when and where
needed.  The delay of loading is significant, and I wanted to avoid
that.

Maybe these all were just shadows of a dwarf, I don't know.  I guess
the real reason is that I felt alone in this adventure (I still do),
and needed to get things done as quickly and as simply as possible,
and in a way that I understood well enough to design and write
reliable code.  The uni-* files and the corresponding properties were
not documented back then, except in short doc strings, so it was hard
for me to know whether changing them to what bidi.c needed was
feasible.  With the little time I had to work on that, and the job
being so huge, I couldn't afford spending too much time on research
and discussions.

> 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.

It's not too late: Emacs 24 is not yet released, and won't be for some
time.  If uni-bidi can be changed to suit the requirements of bidi.c,
I will gladly change bidi.c to use it and throw away the private table
it uses now.  TIA.

> 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.

That would be great, thanks.

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

AFAIK, this needs a change in how uni-mirrored.el is generated,
because UnicodeData.txt doesn't include the necessary information.  So
admin/unidata/unidata-gen.el's way of gleaning the info from
UnicodeData.txt is not appropriate for such a change.

Maybe we should simply expose to Lisp the table built from
BidiMirroring.txt, which bidi.c already creates and uses.