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 19:37:17 +0900 Message-ID: <87r3yxwdr6.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> <87wq8pwjen.fsf@uwakimon.sk.tsukuba.ac.jp> <837g0ptnlj.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 1411814289 28758 80.91.229.3 (27 Sep 2014 10:38:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Sep 2014 10:38:09 +0000 (UTC) Cc: Kenichi Handa , 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 Sat Sep 27 12:38:01 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 1XXpO5-0008OY-9w for ged-emacs-devel@m.gmane.org; Sat, 27 Sep 2014 12:38:01 +0200 Original-Received: from localhost ([::1]:55263 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXpO4-0004UH-Qo for ged-emacs-devel@m.gmane.org; Sat, 27 Sep 2014 06:38:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41967) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXpNu-0004U7-Ge for emacs-devel@gnu.org; Sat, 27 Sep 2014 06:37:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXpNn-0005Rg-18 for emacs-devel@gnu.org; Sat, 27 Sep 2014 06:37:50 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:35664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXpNW-0005K7-QF; Sat, 27 Sep 2014 06:37:27 -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 14FF31C399F; Sat, 27 Sep 2014 19:37:18 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0376F1A3260; Sat, 27 Sep 2014 19:37:17 +0900 (JST) In-Reply-To: <837g0ptnlj.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:174735 Archived-At: Eli Zaretskii writes: > 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? No, I've studied the coded character sets that are actually used by real people in this world, and concluded that for practical purposes, the Unicode coded character set plus the PUA permits representing all of them satisfactorily for a TTY, and that the additional burden of disambiguating them (eg, for font choice in a GUI) should be handled by markup (eg, the XML lang attribute in text/* representations, and text properties in Emacs). > 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. If :unify-map really means that all of those character sets are mapped injectively into the Emacs coded character set, OK, it's just Mule code all over again. Since CNS alone has about 80,000 characters in it and that's just for a start, no, there is not enough space in the Unicode PUA for complete (and mostly redundant) copies of a double handful of Han character sets.