Hello! Mike Gran <spk...@yahoo.com> 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’.
