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:46:27 +0200 Message-ID: <83o9y2xc3w.fsf@gnu.org> References: <878tpsqtzl.fsf@fencepost.gnu.org> <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> <87efyy4k4c.fsf@fencepost.gnu.org> <87mvdmv3kg.fsf@elektro.pacujo.net> <8760ka4drd.fsf@fencepost.gnu.org> <87h93uv1kl.fsf@elektro.pacujo.net> <871suy4cha.fsf@fencepost.gnu.org> <877f4qv0a8.fsf@elektro.pacujo.net> <87wpcq2w58.fsf@fencepost.gnu.org> <871suyuyby.fsf@elektro.pacujo.net> <83tw7uxg1o.fsf@gnu.org> <87efyyt7jb.fsf@elektro.pacujo.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1487268631 14831 195.159.176.226 (16 Feb 2017 18:10:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Feb 2017 18:10:31 +0000 (UTC) Cc: guile-user@gnu.org, dak@gnu.org To: Marko Rauhamaa Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Feb 16 19:10:27 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 1ceQVb-0003MI-Ni for guile-user@m.gmane.org; Thu, 16 Feb 2017 19:10:23 +0100 Original-Received: from localhost ([::1]:48969 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ceQVh-0003GG-Kd for guile-user@m.gmane.org; Thu, 16 Feb 2017 13:10:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ceQ87-0007hI-Mb for guile-user@gnu.org; Thu, 16 Feb 2017 12:46:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ceQ84-0005Ad-Js for guile-user@gnu.org; Thu, 16 Feb 2017 12:46:07 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56742) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ceQ84-0005AW-HS; Thu, 16 Feb 2017 12:46:04 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2474 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ceQ83-00028L-ES; Thu, 16 Feb 2017 12:46:04 -0500 In-reply-to: <87efyyt7jb.fsf@elektro.pacujo.net> (message from Marko Rauhamaa on Thu, 16 Feb 2017 18:38: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:13266 Archived-At: > From: Marko Rauhamaa > Cc: dak@gnu.org, guile-user@gnu.org > Date: Thu, 16 Feb 2017 18:38:48 +0200 > > Eli Zaretskii : > > > Why is that a problem? Unicode generally mandates that equivalent > > character (a.k.a. "codepoint") sequences shall be handled the same by > > applications, both while processing the text (e.g., searching it etc.) > > and when displaying it. > > As I just said in another reply, emacs 25.1 isn't handling them the same > even though it maybe should. Yes, it does -- where that's TRT. For example, when displaying them. And sometimes this is a user option; e.g., see character-folding in Isearch. > Now, should Guile handle them the same? IMO, Guile should provide the facilities to handle them the same, and leave for the higher-level code to use whatever is suitable. In any case, this is unrelated to how strings are implemented, because the basic level of string implementation _must_ support binary, character by character (and byte by byte) comparison. Otherwise, you won't be able to compare file names equal, for example, at least on Unix and Windows (macOS is another matter).