unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Marko Rauhamaa <marko@pacujo.net>
Cc: guile-user@gnu.org
Subject: Re: Running script from directory with UTF-8 characters
Date: Tue, 22 Dec 2015 22:59:05 +0200	[thread overview]
Message-ID: <83wps6p5d2.fsf@gnu.org> (raw)
In-Reply-To: <87oadicjbc.fsf@elektro.pacujo.net> (message from Marko Rauhamaa on Tue, 22 Dec 2015 22:36:07 +0200)

> From: Marko Rauhamaa <marko@pacujo.net>
> Date: Tue, 22 Dec 2015 22:36:07 +0200
> Cc: guile-user@gnu.org
> 
> By setting the character set artificially to Latin-1 in Guile, all
> pathnames are accessible to it.

No, they aren't, not as file names.  E.g., you cannot meaningfully
downcase or upcase such "characters", you cannot count characters (as
opposed to bytes), you cannot calculate how much screen estate will be
needed to display them, with some Far Eastern encodings you cannot
correctly search them for some specific ASCII characters (because they
can be part of a multibyte sequence), etc. etc.  IOW, you cannot work
with file names as human-readable text, which is something many
programs need to do.

File names _are_ strings, there's no way around that.  They are
strings because _people_ name files and give them meaningful names and
extensions.  If Guile cannot easily work with file names encoded in a
codeset other than the current locale's one, then Guile should be
extended to allow a program to tell it in which encoding to interpret
a particular name.  (I think Guile already supports that, but maybe I
misremember.)  But lobbying for treating file names as byte streams,
let alone Latin-1 characters, is a large step backwards, to 1990s when
we didn't know better.  We've come a long way since then and learned a
lot on the way.



  reply	other threads:[~2015-12-22 20:59 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-21 21:09 Running script from directory with UTF-8 characters Vicente Vera
2015-12-21 23:19 ` Marko Rauhamaa
2015-12-22  0:34   ` Chris Vine
2015-12-22  1:14     ` Marko Rauhamaa
2015-12-22 14:21       ` Chris Vine
2015-12-22 15:55         ` Marko Rauhamaa
2015-12-22 20:12           ` Chris Vine
2015-12-22 20:36             ` Marko Rauhamaa
2015-12-22 20:59               ` Eli Zaretskii [this message]
2015-12-22 21:39                 ` Marko Rauhamaa
2015-12-23 18:28                   ` Eli Zaretskii
2015-12-23 19:18                     ` Marko Rauhamaa
2015-12-23 19:33                       ` Eli Zaretskii
2015-12-23 21:15                         ` Marko Rauhamaa
2015-12-23 21:53                         ` David Kastrup
2015-12-23 22:20                           ` Marko Rauhamaa
2015-12-23 22:25                             ` David Kastrup
2015-12-24 16:13                   ` Barry Schwartz
2015-12-22 14:32   ` Vicente Vera
2015-12-22 15:56     ` Marko Rauhamaa
2015-12-26  1:57       ` Vicente Vera

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83wps6p5d2.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=guile-user@gnu.org \
    --cc=marko@pacujo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).