[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: unicode status
From: |
Ludovic Courtès |
Subject: |
Re: unicode status |
Date: |
Mon, 14 Sep 2009 00:08:42 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
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’.