From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Fri, 26 Sep 2014 17:21:08 +0200 Message-ID: <877g0qo1az.fsf@fencepost.gnu.org> 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 X-Trace: ger.gmane.org 1411745001 30070 80.91.229.3 (26 Sep 2014 15:23:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Sep 2014 15:23:21 +0000 (UTC) Cc: Dmitry Antipov , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 26 17:23:14 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 1XXXMY-00087q-Cd for ged-emacs-devel@m.gmane.org; Fri, 26 Sep 2014 17:23:14 +0200 Original-Received: from localhost ([::1]:49827 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXXMX-0004o4-Ty for ged-emacs-devel@m.gmane.org; Fri, 26 Sep 2014 11:23:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34078) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXXL5-0002tp-4k for emacs-devel@gnu.org; Fri, 26 Sep 2014 11:21:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXXL4-0007bX-Co for emacs-devel@gnu.org; Fri, 26 Sep 2014 11:21:43 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:35845) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXXL4-0007aw-AP for emacs-devel@gnu.org; Fri, 26 Sep 2014 11:21:42 -0400 Original-Received: from localhost ([127.0.0.1]:41474 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXXKw-0003Hk-QR; Fri, 26 Sep 2014 11:21:35 -0400 Original-Received: by lola (Postfix, from userid 1000) id EC865E0D4E; Fri, 26 Sep 2014 17:21:08 +0200 (CEST) In-Reply-To: <83iokato6x.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 26 Sep 2014 18:07:50 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.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:174725 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. > Can ICU support that? If not, we cannot base our implementation on > ICU without a lot of redesign. Well, the context here was the integration of Emacs and GUILE, and it would be optimistic to think that efficient string/buffer handling will not leave us with a lot of redesign either way. Matching GUILE and Emacs allows us to compare and integrate the best approaches from either side. With ICU, it will always be "take it or leave it". It may be good enough. If it isn't in some small respect, getting it changed or fixed is not under our control. -- David Kastrup