From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: handa@gnu.org (K. Handa) Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Mon, 29 Sep 2014 22:17:46 +0900 Message-ID: <874mvqefb9.fsf@gnu.org> References: <837g0ptnlj.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1411999196 7590 80.91.229.3 (29 Sep 2014 13:59:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Sep 2014 13:59:56 +0000 (UTC) Cc: stephen@xemacs.org, dmantipov@yandex.ru, dak@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 29 15:59:48 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 1XYbUR-0003vr-H8 for ged-emacs-devel@m.gmane.org; Mon, 29 Sep 2014 15:59:47 +0200 Original-Received: from localhost ([::1]:36907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYbUR-0002EI-0r for ged-emacs-devel@m.gmane.org; Mon, 29 Sep 2014 09:59:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYbTw-0001jA-Nr for emacs-devel@gnu.org; Mon, 29 Sep 2014 09:59:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XYbTr-0001hq-9d for emacs-devel@gnu.org; Mon, 29 Sep 2014 09:59:16 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYbTr-0001fz-78 for emacs-devel@gnu.org; Mon, 29 Sep 2014 09:59:11 -0400 Original-Received: from fl1-122-134-99-48.iba.mesh.ad.jp ([122.134.99.48]:43773 helo=shatin) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1XYbTl-0001Nf-6o; Mon, 29 Sep 2014 09:59:05 -0400 Original-Received: from handa by shatin with local (Exim 4.82) (envelope-from ) id 1XYapm-0006hM-Ur; Mon, 29 Sep 2014 22:17:46 +0900 In-Reply-To: <837g0ptnlj.fsf@gnu.org> (message from Eli Zaretskii on Sat, 27 Sep 2014 12:32:56 +0300) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:174806 Archived-At: In article <837g0ptnlj.fsf@gnu.org>, Eli Zaretskii writes: > > 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?) > I take it that you have studied the charsets for which we use > codepoints above 0x10FFFF, and concluded that they all fit in the > 2*64K+6.4K PUA space provided by Unicode? We have several quite large > character sets which need that (grep mule-conf.el for ":unify-map" to > see the list, and see etc/charsets/ for the map files). I'm not sure > the PUA space is large enough, but I didn't sum all the numbers. > In any case, the question why we don't use PUA for this is best > addressed to Handa-san (CC'ed). The biggest character set is GB18030 which includes the whole Unicode characters (including PUA) plus several its own PUAs. So, the Unicode character code points are simply not enough to support the full GB18030. In addition, almost all 2-byte CJK character sets contain their own PUAs. As Emacs doesn't unify characters in those PUAs with Unicode' PUA characters, we can handle multiple those character sets at the same time. --- Kenichi Handa handa@gnu.org