From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.lisp.guile.user Subject: Re: guile can't find a chinese named file Date: Thu, 16 Feb 2017 19:41:54 +0200 Message-ID: <83poiixcbh.fsf@gnu.org> References: <878tpsqtzl.fsf@fencepost.gnu.org> <87zii8bcdw.fsf@elektro.pacujo.net> <87y3xspcux.fsf@fencepost.gnu.org> <578885360.4452806.1487105647708@mail.yahoo.com> <87r330cwhj.fsf@elektro.pacujo.net> <191859705.4469709.1487109121157@mail.yahoo.com> <20170214221914.1483ddb1@bother.homenet> <20170215091832.GA28017@tuxteam.de> <83inobz8yl.fsf@gnu.org> <20170215202056.GB3723@tuxteam.de> <83d1ejyz2e.fsf@gnu.org> <87y3x7kvwr.fsf@elektro.pacujo.net> <837f4qzo31.fsf@gnu.org> <87h93u4q5e.fsf@elektro.pacujo.net> <831suyzm11.fsf@gnu.org> <83zihmy6wb.fsf@gnu.org> <87wpcq38sa.fsf@elektro.pacujo.net> <83wpcqxgq5.fsf@gnu.org> <87inoat7ob.fsf@elektro.pacujo.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1487268594 4713 195.159.176.226 (16 Feb 2017 18:09:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Feb 2017 18:09:54 +0000 (UTC) Cc: guile-user@gnu.org To: Marko Rauhamaa Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Feb 16 19:09:50 2017 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ceQV0-0000eu-0M for guile-user@m.gmane.org; Thu, 16 Feb 2017 19:09:46 +0100 Original-Received: from localhost ([::1]:48953 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ceQV5-0002uH-ML for guile-user@m.gmane.org; Thu, 16 Feb 2017 13:09:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51793) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ceQ3q-0002fp-Ua for guile-user@gnu.org; Thu, 16 Feb 2017 12:41:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ceQ3n-0003Ai-Sb for guile-user@gnu.org; Thu, 16 Feb 2017 12:41:43 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ceQ3n-0003Ad-Oh; Thu, 16 Feb 2017 12:41:39 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2473 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ceQ3m-0001k0-3r; Thu, 16 Feb 2017 12:41:39 -0500 In-reply-to: <87inoat7ob.fsf@elektro.pacujo.net> (message from Marko Rauhamaa on Thu, 16 Feb 2017 18:35:48 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:13265 Archived-At: > From: Marko Rauhamaa > Cc: guile-user@gnu.org > Date: Thu, 16 Feb 2017 18:35:48 +0200 > > Eli Zaretskii : > > > You assume that Emacs concatenates strings by just splicing its bytes. > > But that's a far cry from what Emacs does, precisely to countermand > > such problems. > > Good to hear. If Guile is to adopt a similar approach, it should pay > attention to these details as well. Indeed. > > The important point for Guile is that the solution is there, in Free > > Software, documented well enough, and people who understand the > > implementation and can explain its subtleties are still here, ready to > > help. All it takes is for Guile to decide it wants to implement > > something similar. > > It would be important for Guile to be a sufficient basis for emacs. That's not my point. My point is that the Emacs model, or some minor variant thereof, should be a good model for Guile (or any other environment that seeks to support complex multi-lingual applications), _regardless_ of whether Guile will ever become the core of the Emacs Lisp interpreter. IOW, it's good for Guile itself. > On the other hand, emacs' needs might be far too high for any simple > string type. For example, Guile might treat strings as simple > sequences of code points while emacs might impose some Unicode > normalization requirements or vice versa. > > For example, what should > > (string= "Åström" "Åström") > > return? > > Emacs 25.1 doesn't see the strings as equal. As it should, IMO. Testing strings for equivalence under canonical or compatibility decompositions is not the job of string=, it requires a separate API. (Emacs provides in ucs-normalize.el the functionality required for that.) There are situations where you want the former, and others where you want the latter. That's why Unicode normalization is not implemented in Emacs on the same level as the string data type, and the application needs to explicitly request normalization in order for it to happen. In general, string equivalence is in many use cases an application-level feature (think interactive text searching), and needs to be language- and locale-sensitive to satisfy users (e.g., it turns out users of Spanish locales don't consider "ñ" (one character), to be equivalent to "ñ" (two characters)).