RE: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Rob Browning
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

Re: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Rob Browning
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

Re: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Mike Gran
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

Re: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Jean Abou Samra
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

Re: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Eli Zaretskii
> 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

Re: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Eli Zaretskii
> 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

Re: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Jean Abou Samra
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

Re: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Jean Abou Samra
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 >

RE: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Maxime Devos
>> >> 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

Re: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Eli Zaretskii
> 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

RE: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Maxime Devos
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

Re: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Eli Zaretskii
> 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

RE: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Maxime Devos
>* 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

Re: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Jean Abou Samra
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

Re: Improving the handling of system data (env, users, paths, ...)

2024-07-07 Thread Jean Abou Samra
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

Re: Improving the handling of system data (env, users, paths, ...)

2024-07-06 Thread Eli Zaretskii
> 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 >

Re: Improving the handling of system data (env, users, paths, ...)

2024-07-06 Thread tomas
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

Improving the handling of system data (env, users, paths, ...)

2024-07-06 Thread Rob Browning
* 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