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: Emacs rewrite in a maintainable language Date: Fri, 16 Oct 2015 18:14:27 +0300 Message-ID: <83k2qm6e24.fsf@gnu.org> References: <561A19AB.5060001@cumego.com> <87io6dl0h0.fsf@wanadoo.es> <87lhb82qxc.fsf@gmail.com> <87oag4jk74.fsf@wanadoo.es> <87k2qrki45.fsf@wanadoo.es> <8737xf9je9.fsf@fencepost.gnu.org> <87pp0fm0j3.fsf@gnu.org> <83r3kv54bg.fsf@gnu.org> <851tcuhnh2.fsf@iznogoud.viz> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1445008771 27756 80.91.229.3 (16 Oct 2015 15:19:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Oct 2015 15:19:31 +0000 (UTC) Cc: ludo@gnu.org, emacs-devel@gnu.org To: Wolfgang Jenkner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 16 17:19:22 2015 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 1Zn6mv-0005cJ-CE for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 17:19:21 +0200 Original-Received: from localhost ([::1]:54335 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn6mu-0001c9-SJ for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 11:19:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn6iE-0002CH-4A for emacs-devel@gnu.org; Fri, 16 Oct 2015 11:14:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn6iA-0003uK-Ue for emacs-devel@gnu.org; Fri, 16 Oct 2015 11:14:30 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:54747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn6iA-0003u0-Nh; Fri, 16 Oct 2015 11:14:26 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NWB00A00J1SK700@mtaout28.012.net.il>; Fri, 16 Oct 2015 18:13:43 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWB006Q9JMVI650@mtaout28.012.net.il>; Fri, 16 Oct 2015 18:13:43 +0300 (IDT) In-reply-to: <851tcuhnh2.fsf@iznogoud.viz> 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.184 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:191762 Archived-At: > From: Wolfgang Jenkner > Cc: ludo@gnu.org (Ludovic Court=E8s), emacs-devel@gnu.org > Date: Fri, 16 Oct 2015 16:55:37 +0200 >=20 > On Fri, Oct 16 2015, Eli Zaretskii wrote: >=20 > > Yes, but libunistring is not a good basis for Emacs's i18n featur= es, > > because it relies on the underlying C library for most of its > > features. That doesn't allow writing programs that behave exactl= y the > > same on any platform, something that Emacs must support. =20 >=20 > IIUC, the behaviour of the recently added `string-collate-lessp' an= d > `string-collate-equalp' already depends on libc (and the locale dat= a). Yes, but these two functions are not called by anything else, they exist so Lisp applications could use locale-specific collation data. I wasn't talking about that, I was talking about stuff like decoding = a Latin-1 file into the internal UTF-8 based representation of characters, or vice versa. Emacs does that all the time. What libunistring does is call the libc's mbstowc, or some such. That requires libc to support all the encodings Emacs needs to support, which I think doesn't happen even with glibc, let alone other system libraries. > (Lest this be interpreted as criticism: IMHO, depending on POSIX > facilities is a good thing, even for emacs.) Emacs should first and foremost present the same behavior and capabilities on all platforms. Different platforms implement Posix t= o different degrees, so relying on Posix capabilities provided by the platform has its limits, and interferes with the above goal of presenting the same behavior. Basing i18n on locale-specific behavior is especially wrong.