> From: l...@gnu.org (Ludovic Courtès)
> Cc: guile-user@gnu.org
> Date: Thu, 16 Jan 2014 14:03:05 +0100
>
> Eli Zaretskii skribis:
>
> >> From: l...@gnu.org (Ludovic Courtès)
> >> Date: Thu, 16 Jan 2014 00:29:06 +0100
> >>
> >> Does anyone know of systems where the file name encoding is commonl
Eli Zaretskii writes:
> Windows stores file names on disk encoded in UTF-16, but converts them
> to the current codepage if you use Posix-style interfaces like 'open'
> and 'rename'. (There are parallel APIs that accept UTF-16 encoded
> file names.)
Okay, so on Windows we should use the parallel
> Date: Thu, 16 Jan 2014 15:07:43 +0100
> From: John Darrington
> Cc: Eli Zaretskii , guile-user@gnu.org
>
> If you know that the filename was always obtained using the Guile's
> interface then the issue is never pertinent.The problem comes when a
> function
> is aske to open a non-ascii na
On Thu, Jan 16, 2014 at 02:03:05PM +0100, Ludovic Court??s wrote:
Eli Zaretskii skribis:
>> From: l...@gnu.org (Ludovic Court??s)
>> Date: Thu, 16 Jan 2014 00:29:06 +0100
>>
>> Does anyone know of systems where the file name encoding is commonly
>> different fr
Eli Zaretskii skribis:
>> From: l...@gnu.org (Ludovic Courtès)
>> Date: Thu, 16 Jan 2014 00:29:06 +0100
>>
>> Does anyone know of systems where the file name encoding is commonly
>> different from locale encoding? Is it the case on Windows?
>
> Windows stores file names on disk encoded in UTF-1
> From: l...@gnu.org (Ludovic Courtès)
> Date: Thu, 16 Jan 2014 00:29:06 +0100
>
> Does anyone know of systems where the file name encoding is commonly
> different from locale encoding? Is it the case on Windows?
Windows stores file names on disk encoded in UTF-16, but converts them
to the curre
> From: Mark H Weaver
> Date: Wed, 15 Jan 2014 16:47:45 -0500
> Cc: guile-user@gnu.org
>
> > All guile needs to know is what encoding the person creating the
> > filesystem has adopted in naming files and which it needs to map to.
>
> Right, but how does it know that? The closest thing we have
> Date: Wed, 15 Jan 2014 21:42:57 +
> From: Chris Vine
> Cc: m...@netris.org, guile-user@gnu.org
>
> I am not sure what you mean, as I am not talking about internal use.
Then I probably didn't understand why you mentioned the external
encoding. How is that relevant to the issue at hand?
I'
> From: Mark H Weaver
> Cc: ch...@cvine.freeserve.co.uk, guile-user@gnu.org
> Date: Wed, 15 Jan 2014 16:34:26 -0500
>
> Well, I understand that MS has standardized on UTF-16 (right?)
Right.
> but what matters from Guile's perspective is the encoding used by
> the POSIX-style interfaces that Gu
Chris Vine skribis:
> So far as filenames are concerned,
> this seems to me to be something for which a fluid would be just the
> thing - it could default to the locale encoding but a user could set it
> to something else. I suppose command lines and environmental variables
> are less problemati
orm part of a single
business unit. More likely still in other than Asia the administrator
has a policy of only using ASCII names for files served across wide
area networks.
Leaving that aside, the idea that a library should not enable the
program to choose its filename encoding as a configurati
Chris Vine writes:
> POSIX system calls are encoding agnostic. The filename is just a series
> of bytes terminating with a NUL character.
Yes, I know, but conceptually these things are strings. Unless you're
going to treat these filenames as black boxes to be copied from one
place to another bu
On Wed, 15 Jan 2014 23:00:18 +0200
Eli Zaretskii wrote:
> > Date: Wed, 15 Jan 2014 19:50:51 +
> > From: Chris Vine
> > Cc: guile-user@gnu.org
> >
> > POSIX system calls are encoding agnostic. The filename is just a
> > series of bytes terminating with a NUL character. All guile needs
> > t
Eli Zaretskii writes:
>> From: Mark H Weaver
>> Date: Wed, 15 Jan 2014 13:14:39 -0500
>> Cc: guile-user@gnu.org
>>
>> My hope is that this will become less of an issue over time, as systems
>> increasingly standardize on UTF-8. I see no other good solution.
>>
>> Thoughts?
>
> MS-Windows file
> Date: Wed, 15 Jan 2014 19:50:51 +
> From: Chris Vine
> Cc: guile-user@gnu.org
>
> POSIX system calls are encoding agnostic. The filename is just a series
> of bytes terminating with a NUL character. All guile needs to know is
> what encoding the person creating the filesystem has adopted
rnal string
> > representation (ISO-8859-1/UTF-32) to narrow string filename
> > encoding when looking up the file? Does it assume filenames are in
> > locale encoding (not particularly safe on networked file systems)
> > or does it provide a fluid for this? (glib caters for t
> From: Mark H Weaver
> Date: Wed, 15 Jan 2014 13:14:39 -0500
> Cc: guile-user@gnu.org
>
> My hope is that this will become less of an issue over time, as systems
> increasingly standardize on UTF-8. I see no other good solution.
>
> Thoughts?
MS-Windows filesystems will not standardize on UTF
Chris Vine writes:
> A number of guile's scheme procedures look-up or reference files on a
> file system (open-file, load and so forth).
>
> How does guile translate filenames from its internal string
> representation (ISO-8859-1/UTF-32) to narrow string filename encoding
&
Hi,
A number of guile's scheme procedures look-up or reference files on a
file system (open-file, load and so forth).
How does guile translate filenames from its internal string
representation (ISO-8859-1/UTF-32) to narrow string filename encoding
when looking up the file? Does it a
19 matches
Mail list logo
