From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: idn.el and confusables.txt Date: Wed, 18 May 2011 03:38:31 -0400 Message-ID: References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1305704324 3784 80.91.229.12 (18 May 2011 07:38:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 18 May 2011 07:38:44 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 18 09:38:39 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 1QMbL5-0007Hu-DW for ged-emacs-devel@m.gmane.org; Wed, 18 May 2011 09:38:39 +0200 Original-Received: from localhost ([::1]:43783 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMbL5-00026a-0a for ged-emacs-devel@m.gmane.org; Wed, 18 May 2011 03:38:39 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:34002) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMbL0-00023n-TY for emacs-devel@gnu.org; Wed, 18 May 2011 03:38:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMbKz-0005zI-Qa for emacs-devel@gnu.org; Wed, 18 May 2011 03:38:34 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:39006) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMbKz-0005zE-On for emacs-devel@gnu.org; Wed, 18 May 2011 03:38:33 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QMbKx-0003tU-B3; Wed, 18 May 2011 03:38:31 -0400 In-reply-to: (message from handa on Wed, 18 May 2011 14:23:26 +0900) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:139479 Archived-At: > From: handa > 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.