From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Sat, 27 Sep 2014 17:35:12 +0900 Message-ID: <87wq8pwjen.fsf@uwakimon.sk.tsukuba.ac.jp> References: <54193A70.9020901@member.fsf.org> <87lhp6h4zb.fsf@panthera.terpri.org> <87k34qo4c1.fsf@fencepost.gnu.org> <54257C22.2000806@yandex.ru> <83iokato6x.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1411806967 13295 80.91.229.3 (27 Sep 2014 08:36:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Sep 2014 08:36:07 +0000 (UTC) Cc: Dmitry Antipov , dak@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 27 10:35:59 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 1XXnTx-0006B3-5a for ged-emacs-devel@m.gmane.org; Sat, 27 Sep 2014 10:35:57 +0200 Original-Received: from localhost ([::1]:55007 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXnTw-0003dt-Pq for ged-emacs-devel@m.gmane.org; Sat, 27 Sep 2014 04:35:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52184) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXnTo-0003da-Hr for emacs-devel@gnu.org; Sat, 27 Sep 2014 04:35:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXnTj-0001Py-2N for emacs-devel@gnu.org; Sat, 27 Sep 2014 04:35:48 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:33683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXnTS-0001LV-Kc; Sat, 27 Sep 2014 04:35:26 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id B3E581C3AC8; Sat, 27 Sep 2014 17:35:12 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A27F41A3260; Sat, 27 Sep 2014 17:35:12 +0900 (JST) In-Reply-To: <83iokato6x.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:174731 Archived-At: Eli Zaretskii writes: > > Date: Fri, 26 Sep 2014 18:45:54 +0400 > > From: Dmitry Antipov > > Cc: emacs-devel@gnu.org > > > > Why not just use ICU? > > Emacs needs to be able to extend the Unicode code-point space for raw > 8-bit bytes and for a couple of character sets that are not unified. No, you don't. There's plenty of private space for those purposes (unless you know of private character sets that use more than two whole planes?) Emacs would simply use an indirect representation for private space. (That is, code points in private space are not necessarily identical to the input code points, but rather are indexes into an auxiliary table which implements the disjoint sum of the private code spaces in use.) Since this is private space, you need to build a table of attributes for these characters (I/O representation, UCD properties, glyphs, etc) anyway. For Unicode input using private space, you just record that as the I/O representation. > Can ICU support that? Maybe it would be unhappy if you used a lone surrogate representation (or other representation using integers outside of the Unicode character space) for those "extended code points", but as proposed above you can efficiently use private space in practice.