> From: Marko Rauhamaa
> Cc: Eli Zaretskii , guile-user@gnu.org
> Date: Thu, 16 Feb 2017 23:13:35 +0200
>
> Python uses the surrogate hole in the middle of the Unicode range to
> represent such stray bytes, but only when naming files.
IMO, it makes no sense to limit this to file names, because
> From: David Kastrup
> Cc: Marko Rauhamaa , guile-user@gnu.org
> Date: Thu, 16 Feb 2017 21:52:48 +0100
>
> Eli Zaretskii writes:
>
> > Yes, to be viable in real-life situation, Guile needs to support
> > character strings with occasional embedded raw bytes that cannot be
> > interpreted as ch
David Kastrup :
> Eli Zaretskii writes:
>> Yes, to be viable in real-life situation, Guile needs to support
>> character strings with occasional embedded raw bytes that cannot be
>> interpreted as characters.
>
> They can be interpreted as "characters", just not inside the _Unicode_
> character ra
Eli Zaretskii writes:
>> From: Marko Rauhamaa
>> Cc: d...@gnu.org, guile-user@gnu.org
>> Date: Thu, 16 Feb 2017 21:35:12 +0200
>>
>> >> If emacs managed to restore a binary/text unification (and infect Guile
>> >> in the process), that would be quite an accomplishment.
>> >
>> > I don't unders
Le 16/02/2017 à 20:18, sirgazil a écrit :
Amirouche says:
What block you from contributing to the wide ecosystem of GNU Guile?
I think about Guile (and GuixSD) almost every day, but I don't contribute as
much as I'd like mostly because of lack of resources to do so. Sadly, it's hard
to find
> From: Marko Rauhamaa
> Cc: d...@gnu.org, guile-user@gnu.org
> Date: Thu, 16 Feb 2017 21:35:12 +0200
>
> >> If emacs managed to restore a binary/text unification (and infect Guile
> >> in the process), that would be quite an accomplishment.
> >
> > I don't understand what "binary/text unificati
Eli Zaretskii :
>> From: Marko Rauhamaa
>> You could leave character strings to application libraries for
>> newsreaders, IRC clients etc, and have a separate byte string data
>> type for the system interface.
>
> I don't know what you mean by "application libraries", but if that's
> something ap
Amirouche says:
> What block you from contributing to the wide ecosystem of GNU Guile?
I think about Guile (and GuixSD) almost every day, but I don't contribute as
much as I'd like mostly because of lack of resources to do so. Sadly, it's hard
to find the opportunity to immerse yourself in libre
Mike Gran writes:
> On Thursday, February 16, 2017 9:39 AM, Marko Rauhamaa
> wrote:
>> Eli Zaretskii :
>
>>> You assume that Emacs concatenates strings by just splicing its bytes.
>>> But that's a far cry from what Emacs does, precisely to countermand
>>> such problems.
>
>> Good to hear. If Gu
> From: Marko Rauhamaa
> Cc: d...@gnu.org, guile-user@gnu.org
> Date: Thu, 16 Feb 2017 20:38:31 +0200
>
> Eli Zaretskii :
>
> > In any case, this is unrelated to how strings are implemented, because
> > the basic level of string implementation _must_ support binary,
> > character by character (
Eli Zaretskii :
> In any case, this is unrelated to how strings are implemented, because
> the basic level of string implementation _must_ support binary,
> character by character (and byte by byte) comparison. Otherwise, you
> won't be able to compare file names equal, for example, at least on
>
> From: Marko Rauhamaa
> Cc: d...@gnu.org, guile-user@gnu.org
> Date: Thu, 16 Feb 2017 18:38:48 +0200
>
> Eli Zaretskii :
>
> > Why is that a problem? Unicode generally mandates that equivalent
> > character (a.k.a. "codepoint") sequences shall be handled the same by
> > applications, both whi
> From: Marko Rauhamaa
> Cc: guile-user@gnu.org
> Date: Thu, 16 Feb 2017 18:35:48 +0200
>
> Eli Zaretskii :
>
> > You assume that Emacs concatenates strings by just splicing its bytes.
> > But that's a far cry from what Emacs does, precisely to countermand
> > such problems.
>
> Good to hear. I
Eli Zaretskii :
> You assume that Emacs concatenates strings by just splicing its bytes.
> But that's a far cry from what Emacs does, precisely to countermand
> such problems.
Good to hear. If Guile is to adopt a similar approach, it should pay
attention to these details as well.
> The important
Eli Zaretskii :
> Why is that a problem? Unicode generally mandates that equivalent
> character (a.k.a. "codepoint") sequences shall be handled the same by
> applications, both while processing the text (e.g., searching it etc.)
> and when displaying it.
As I just said in another reply, emacs 25
> From: Marko Rauhamaa
> Cc: to...@tuxteam.de, guile-user@gnu.org
> Date: Thu, 16 Feb 2017 09:02:09 +0200
>
> Eli Zaretskii :
>
> >> From: Marko Rauhamaa
> >> Cc: to...@tuxteam.de, guile-user@gnu.org
> >> Date: Thu, 16 Feb 2017 08:15:57 +0200
> >>
> >> It is possible to have illegal Unicode
> From: Marko Rauhamaa
> Date: Thu, 16 Feb 2017 14:14:41 +0200
> Cc: guile-user@gnu.org
>
> (On the other side of the equation, expressing a filename in Unicode may
> not produce an unambiguous code point sequence... http://unicode.org/faq/normalization.html>)
Why is that a problem? Unicode ge
> From: Marko Rauhamaa
> Cc: guile-user@gnu.org
> Date: Thu, 16 Feb 2017 09:16:21 +0200
>
> If I understood it correctly, someone just told us emacs maps illegal
> UTF-8 to another form of illegal UTF-8 and back. That's better in that
> it's bytes to bytes (leaving Unicode out), but it's not imme
Please do not use 0.75.0, use 0.75.3 instead. I had to make a few last-minute
changes. — Matt
> On Feb 16, 2017, at 6:02 AM, Matt Wette wrote:
>
> NYACC version 0.75.0 has been released. This is primarily an update to the
> C99 C preprocessor.
> I have also started working on a manual for th
NYACC version 0.75.0 has been released. This is primarily an update to the C99
C preprocessor.
I have also started working on a manual for the C99 parser. Lot’s of work to
go still.
NYACC, for Not Yet Another Compiler Compiler!, is set of guile modules for
generating parsers and lexical analy
David Kastrup :
> Marko Rauhamaa writes:
>> And the point of bringing concatenation into the discussion was that
>> remapping byte sequences to byte sequences breaks concatenation
>> additivity:
>>
>>U(x) + U(y) = U(x + y)
>
> But Emacs' implementation doesn't in any respect "break concatenat
Marko Rauhamaa writes:
> David Kastrup :
>> It's still irrelevant since split does not _use_ the existing file name
>> for constructing new file names.
>
> Split was just an example of a command that concatenates bytes sequences
> to get pathnames, nothing more.
>
> Such concatenation is commonpl
David Kastrup :
> It's still irrelevant since split does not _use_ the existing file name
> for constructing new file names.
Split was just an example of a command that concatenates bytes sequences
to get pathnames, nothing more.
Such concatenation is commonplace in Linux programs of all kinds.
Marko Rauhamaa writes:
> David Kastrup :
>
>> Marko Rauhamaa writes:
>>> You probably cannot produce valid UTF-8 out of invalid UTF-8 snippets
>>> with split(1). However split(1) does form filenames out of its
>>> arguments by concatenation:
>>>
>>> split --additional-suffix=suffix file pref
David Kastrup :
> Marko Rauhamaa writes:
>> You probably cannot produce valid UTF-8 out of invalid UTF-8 snippets
>> with split(1). However split(1) does form filenames out of its
>> arguments by concatenation:
>>
>> split --additional-suffix=suffix file prefix
>>
>> produces these kinds of f
Marko Rauhamaa writes:
> David Kastrup :
>
>> Marko Rauhamaa writes:
>>> That operation fails if you try to translate the snippets to strings
>>> before concatenation. Such concatenation operations are commonplace
>>> when dealing with filenames (eg, split(1)).
>>
>> split(1) does not "deal with
David Kastrup :
> Marko Rauhamaa writes:
>> That operation fails if you try to translate the snippets to strings
>> before concatenation. Such concatenation operations are commonplace
>> when dealing with filenames (eg, split(1)).
>
> split(1) does not "deal with filenames" when splitting, but th
Marko Rauhamaa writes:
> Eli Zaretskii :
>
>> Btw, if by "UCS-2" you meant to say that only characters within the
>> BMP are supported in file names on Windows, then this is wrong
>
> No, I'm claiming Windows allows pathnames to contain isolated surrogate
> code points, which cannot be decoded ba
28 matches
Mail list logo
