bug-libunistring
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-libunistring] Changing the appearance of escapes


From: Ludovic Courtès
Subject: [bug-libunistring] Changing the appearance of escapes
Date: Wed, 15 Sep 2010 23:53:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Hello,

Guile stores strings internally either in ISO-8859-1 (if possible) or in
UCS-4.  When doing I/O, strings are converted from/to the input/output
encoding using, e.g., ‘u32_conv_to_encoding’.  I/O ports have a
conversion-failure strategy, the equivalent of ‘ilseq_handler’.

However, libunistring/iconv have their own syntax for escapes, which is
different from Guile’s historical syntax, and also different from that
used in R6RS.  The problem is, we want Guile to emit escapes in either
of these two formats, not that of libunistring/iconv.

Currently, we end up hackily parsing the result of
‘u32_conv_to_encoding’, looking for escape sequences (assuming the
result of the conversion is in an ASCII-compatible encoding), and
rewriting them.  In the worst case, a 6-character libunistring ‘\uNNNN’
escape is converted to a 7-character R6RS ‘\uNNNN;’ escape, which, as
you can imagine, magnifies the kludge.

How would you suggest to improve the situation?

Guile could do the escaping on its own if ‘u32_conv_to_encoding’ could
stop conversion upon failure and return (i) whatever was converted, and
(ii) the offset of the conversion failure (like ‘iconv’ does.)

What do you think?

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]