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: One more string functions change Date: Sun, 29 Jun 2014 18:13:12 +0300 Message-ID: <83r427696f.fsf@gnu.org> References: <53AD8D59.5000207@yandex.ru> <53AD9FDB.80705@cs.ucla.edu> <83simq6spc.fsf@gnu.org> <53AEEBA3.1030706@yandex.ru> <83zjgx54ub.fsf@gnu.org> <53AF7FB9.1030709@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1404054825 6746 80.91.229.3 (29 Jun 2014 15:13:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 Jun 2014 15:13:45 +0000 (UTC) Cc: handa@gnu.org, emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 29 17:13:38 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X1GnR-0003s9-AC for ged-emacs-devel@m.gmane.org; Sun, 29 Jun 2014 17:13:37 +0200 Original-Received: from localhost ([::1]:58010 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1GnQ-00009l-Qr for ged-emacs-devel@m.gmane.org; Sun, 29 Jun 2014 11:13:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1GnI-00008E-BP for emacs-devel@gnu.org; Sun, 29 Jun 2014 11:13:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X1GnC-0004jW-Rb for emacs-devel@gnu.org; Sun, 29 Jun 2014 11:13:28 -0400 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:43119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1GnC-0004jL-Fb; Sun, 29 Jun 2014 11:13:22 -0400 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0N7X00M00R638X00@mtaout24.012.net.il>; Sun, 29 Jun 2014 18:09:27 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7X00JLPRFRZ130@mtaout24.012.net.il>; Sun, 29 Jun 2014 18:09:27 +0300 (IDT) In-reply-to: <53AF7FB9.1030709@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 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:172814 Archived-At: > Date: Sun, 29 Jun 2014 06:53:45 +0400 > From: Dmitry Antipov > CC: Kenichi Handa , emacs-devel@gnu.org > > On 06/28/2014 09:19 PM, Eli Zaretskii wrote: > > > UAX#14, UAX#15, UTS#10, and UTS#18 should all be supported by Emacs. > > (And yes, I should complete my work on bringing the bidirectional > > editing support in line with the additions to UAX#9 in Unicode 6.3.) > > BTW, why do not use ICU plus our own special handling for 0x110000..0x3FFFFF? I don't think this was ever considered. It's possible that we should consider this now, but the answer to your question is not a trivial one in any case. Emacs traditionally exposed to Lisp all the Unicode character properties, as char-tables. If we decide to use ICU, we'd need to think what to do with those char-tables: remove them, populate them using ICU, something else? (Having these databases twice would be an unnecessary bloat, IMO.) Some of these properties need to support very fast access (e.g., for bidi display), and the question is how fast is ICU in this regard. Also, many Unicode features are already implemented, so they should be reworked or refactored, or maybe the corresponding ICU features left unused. And features that depend on Unicode, like font selection, will have to be adapted. IOW, just coming up with a list of pros and cons will probably require some research, IMO.