Re: unicode status

[Ludovic Courtès]

Hello!

Mike Gran <address@hidden> writes:

> ** Ports do transcoding

Speaking of this, would you be willing to implement R6RS’ transcoder
API in ‘r6rs-ports.c’?  :-)

> * The i18n library hasn't been touched.  It should probably move to use
> functions like u32_casecmp from libunistring for unicode-capable
> locale-specific sorting.

Is u32_casecmp locale-dependent?

> But the #ifdef and locale madness in i18n is
> deep.

Heh heh, it’s deep but needed.  It allows us to provide an API with
first-class locale objects, akin to POSIX 2008’s ‘locale_t’, which is
neat IMO.

At any rate, the parts you’re interested in can probably be modified
without touching the #ifdef madness.

> I've avoided hacking it.  Also we'll have to write our own functions
> for locale-string->double and locale-string->int.

We have ‘locale-string->integer’ and ‘locale-string->inexact’, which
currently use strtol(3) and strtod(3) respectively (info "(guile) Number
Input and Output").

> Bruno has some suggestions on how to do that at
> http://savannah.gnu.org/support/?106998

This suggestion could probably be implemented in Scheme, similarly to
‘number->locale-string’.

> * EMACS has a lot of aliases that can be use in the "-*- coding: XXXXX
> -*-" line, like latin-1, that aren't valid encoding names.  The reader
> should be modified to understand the common ones.

Also, currently ‘scm_scan_for_encoding ()’ searches for a “coding:”
string in the ‘SCM_ENCODING_SEARCH_SIZE’ first bytes of the file,
whereas Emacs searches in the first line (or second line if the first is
“#!...”) or in a local variable list less than 3000 characters from the
end of the file (info "(emacs) Specifying File Variables").

Overall, it seems to me that Unicode support is in a very good shape and
the points above aren’t too worrying.

Thanks,
Ludo’.