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
FYI,
I'm not getting responses from bug-gu...@gnu.org
With `--disable-tmpnam' argument to configure, posix.test fails:
missing `tmpnam`.
I think this works. It passes the test and using the let in the repl
generated the
intended result.
patch attached
--- test-suite/tests/posix.test-or
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: Sun, 07 Jul 20
> 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
16 matches
Mail list logo
