Maxime Devos writes:
> I’d rather not. It’s rather stateful and hence non-trivial to compose.
> Also, locale is not only about the encoding of text [file name/env
> encodings/xattr/...], but also about language. Also setting the
> language is excessive in this case.
The proposal would be that yo
Jean Abou Samra writes:
> latin1 locale is a terrible default. Virtually no Linux system these days
> has a locale encoding different than UTF-8. Except perhaps for the "C" locale,
> which people still use by habit with "LC_ALL=C" as a way to say "speak English
> please", although most Linux dist
On Sunday, July 7, 2024 at 08:58:34 AM PDT, Eli Zaretskii wrote:
>> I don't think it's worth it. If anybody's going to work on this problem,
>> I'd recommend simply adding APIs like program-arguments-bytevector,
>> getenv-bytevector and the like, returning raw bytevectors instead of strings,
>> a
Le dimanche 07 juillet 2024 à 18:58 +0300, Eli Zaretskii a écrit :
> Probably. Do you consider it a problem in Emacs or in Pango?
The Pango documentation explicitly states that Pango validates the input
and "renders invalid UTF-8 with a placeholder glyph".
https://docs.gtk.org/Pango/method.La
> From: Jean Abou Samra
> Cc: r...@defaultvalue.org, guile-devel@gnu.org
> Date: Sun, 07 Jul 2024 17:16:31 +0200
>
> There are non-trivial backwards compatibility implications. To give
> a concrete case: LilyPond definitely has code that would break if
> passed a string whose "conversion to UTF-8
> Cc: "j...@abou-samra.fr" ,
> "r...@defaultvalue.org" ,
> "guile-devel@gnu.org"
> From: Maxime Devos
> Date: Sun, 7 Jul 2024 16:59:10 +0200
>
> >> >> Guile is a Scheme implementation, bound by Scheme standards and
> >> >> compatibility
> >> >> with other Scheme implementations (a
Le dimanche 07 juillet 2024 à 17:16 +0200, Jean Abou Samra a écrit :
> From the implementation point of view: conversion from an encoding to
> another could no longer use libiconv, because it stops on invalid
> multibyte sequences. Likewise, Guile could probably not use libiconv
Le dimanche 07 juillet 2024 à 17:25 +0300, Eli Zaretskii a écrit :
>
> If Guile restricts itself to Unicode characters and only them, it will
> lack important features. So my suggestion is not to have this
> restriction.
>
> I think the fact that this discussion is held, and that Rob suggested
>
>> >> Guile is a Scheme implementation, bound by Scheme standards and
>> >> compatibility
>> >> with other Scheme implementations (and backwards compatibility too).
>> >
>> >Yes, I understand that.
>>
>> Going by what you are saying below, I think you don’t.
>
>Thank you for your vote of confiden
> Cc: "r...@defaultvalue.org" ,
> "guile-devel@gnu.org"
> From: Maxime Devos
> Date: Sun, 7 Jul 2024 13:35:27 +0200
>
> >> Guile is a Scheme implementation, bound by Scheme standards and
> >> compatibility
> >> with other Scheme implementations (and backwards compatibility too).
> >
> >Y
Sent from Mail for Windows
From: Eli Zaretskii
Sent: Sunday, 7 July 2024 13:05
To: Jean Abou Samra
Cc: r...@defaultvalue.org; guile-devel@gnu.org
Subject: Re: Improving the handling of system data (env, users, paths, ...)
> From: Jean Abou Samra
> Cc: guile-devel@gnu.org
> Date: Su
> From: Jean Abou Samra
> Cc: guile-devel@gnu.org
> Date: Sun, 07 Jul 2024 12:03:06 +0200
>
> Le dimanche 07 juillet 2024 à 08:33 +0300, Eli Zaretskii a écrit :
> >
> > - The internal representation is a superset of UTF-8, in that it
> > is capable of representing characters for which
>* Problem
>
>System data like environment variables, user names, group names, file
paths and extended attributes (xattr), etc. are on some systems (like
Linux) binary data, and may not be encodable as a string in the current
locale. For Linux, as an example, only the null character is an invalid
Le dimanche 07 juillet 2024 à 08:33 +0300, Eli Zaretskii a écrit :
>
> - The internal representation is a superset of UTF-8, in that it
> is capable of representing characters for which there are no
> Unicode codepoints (such as GB 18030, some of whose characters
> don't have
Le samedi 06 juillet 2024 à 15:32 -0500, Rob Browning a écrit :
> At a minimum, I suggest Guile should produce an error by default
> (instead of generating incorrect data) when the system bytes cannot be
> encoded in the current locale.
I agree that an error would be better than replacing with a
> From: Rob Browning
> Date: Sat, 06 Jul 2024 15:32:17 -0500
>
> * Problem
>
> System data like environment variables, user names, group names, file
> paths and extended attributes (xattr), etc. are on some systems (like
> Linux) binary data, and may not be encodable as a string in the current
>
On Sat, Jul 06, 2024 at 03:32:17PM -0500, Rob Browning wrote:
>
>
> * Problem
>
> System data like environment variables, user names, group names, file
> paths and extended attributes (xattr), etc. are on some systems (like
> Linux) binary data, and may not be encodable as a string in the curren
* Problem
System data like environment variables, user names, group names, file
paths and extended attributes (xattr), etc. are on some systems (like
Linux) binary data, and may not be encodable as a string in the current
locale. For Linux, as an example, only the null character is an invalid
18 matches
Mail list logo