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: Mon, 30 Jan 2017 21:41:23 +0200 Message-ID: <83r33kwd24.fsf@gnu.org> References: <874m0gd3z4.fsf@gnu.org> <87wpdc8rx7.fsf@elektro.pacujo.net> <87poj4r04c.fsf@fencepost.gnu.org> <87k29c8q3b.fsf@elektro.pacujo.net> <87h94gqz34.fsf@fencepost.gnu.org> <87fuk0ctve.fsf@elektro.pacujo.net> <878tpsqtzl.fsf@fencepost.gnu.org> <87zii8bcdw.fsf@elektro.pacujo.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1485805325 29785 195.159.176.226 (30 Jan 2017 19:42:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 30 Jan 2017 19:42:05 +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 Mon Jan 30 20:42:01 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 1cYHpu-0007TC-4v for guile-user@m.gmane.org; Mon, 30 Jan 2017 20:41:58 +0100 Original-Received: from localhost ([::1]:34767 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYHpz-00072d-Cc for guile-user@m.gmane.org; Mon, 30 Jan 2017 14:42:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYHpe-00072V-Hd for guile-user@gnu.org; Mon, 30 Jan 2017 14:41:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cYHpZ-0003Zp-UO for guile-user@gnu.org; Mon, 30 Jan 2017 14:41:42 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35217) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYHpZ-0003Zl-RL; Mon, 30 Jan 2017 14:41:37 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4253 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cYHpY-0001qy-Gx; Mon, 30 Jan 2017 14:41:37 -0500 In-reply-to: <87zii8bcdw.fsf@elektro.pacujo.net> (message from Marko Rauhamaa on Mon, 30 Jan 2017 21:01:31 +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:13151 Archived-At: > From: Marko Rauhamaa > Date: Mon, 30 Jan 2017 21:01:31 +0200 > Cc: guile-user@gnu.org > > UTF-8 beautifully bridges the interpretation gap between 8-bit character > strings and text. However, the interpretation step should be done in the > application and not in the programming language. You can't do that in an environment that specifically targets sophisticated multi-lingual text processing independent of the outside locale. Unless you can interpret byte sequences as characters, you will be unable to even count characters in a range of text, let alone render it for display. And you cannot request applications to do those low-level chores. > Support libraries for Unicode are naturally welcome. Well, in that case Emacs core is one huge "support library". And I don't see why Guile couldn't be another one; it should, IMO. > Plain Unicode text is actually quite a rare programming need. It is > woefully inadequate for the human interface, which generally requires > numerous other typesetting effects. You do need "other typesetting effects", naturally, but that doesn't mean you can get away without more or less full support of Unicode nowadays. You are talking about programming, but we should instead think about applications -- those of them which need to process text, or even access files, as this discussion shows, do need decent Unicode support. E.g., users generally expect that decomposed and composed character sequences behave and are treated identically, although they are different byte-stream wise. > But is also causing unnecessary grief in the computer-computer > interface, where the classic textual naming and textual protocols > are actually cutely chosen octet-aligned binary formats. The universal acceptance of UTF-8 nowadays makes this much less of an issue, IME.