-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jerry James <james(a)xemacs.org> writes:
Aidan Kehoe <kehoea(a)parhasard.net> wrote:
[snip]
> (From the SXEmacs Unix-only perspective, one alternative _might_
be to find
> an ISO-2022 compatible coding system supported by GNU iconv that does what
> my recent changes to the escape-quoted coding system does; that is,
> represent Unicode code points that don’t have a known ISO 2022 mapping using
> UTF-8 escapes. Then one could replace the guts of the Unicode coding systems
> with iconv() calls. But I couldn’t find such an iconv coding system easily;
> maybe one does exist, still.)
I don't understand why we need to worry about SXEmacs. Let the SXEmacs
developers worry about it, if they feel the need. We've got our hands
full with our own project. (Don't interpret this as antipathy for
SXEmacs; I wish the SXEmacs developers well. I'm just being pragmatic.)
Absolutely right, Jerry. :)
And thanks to Aidan for this wonderful proposal. We are currently
checking/discussing the pros and cons of libiconv and friends, from what I
understood so far it is a very promising approach.
However, our decision for or against one of the alternatives is not
something you should bother with or count on, especially as we do not
have:
1. enough insight to foresee consequences
2. enough man-power and competence to migrate faster than you
3. very limited interest in unicode at all (from the developers point)
We would like to see us in an reactive role, that is our final decision
may depend on yours, but conversely you should not necessarily consider us
in your decision.
If all your changes are transparent enough at lisp level, we will surely
implement the necessary compatibility layer at the C level.
Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFEmcNNlMmhrILJOQ4RAt9rAJwPtKb3BsMoExWRmkC9Tfapny5g3ACdG4G0
GWJnQUH0OTMmgQaQy7NltdA=
=3sFO
-----END PGP SIGNATURE-----