Re: Doc Tasks

[Jim Blandy <jimb at red-bean dot com>]

> 	I18n stuff, since my personal interest in this area is strong.  I'm
> going over the "mltext" and "mbapi" stuff from the docs directory, but
> haven't looked at the code itself yet.

It would be awesome to have someone working on this!  Good luck!

However, there are some pretty demanding constraints on this work that
should probably be explained.

According to Stallman, the most important immediate application of
Guile is to replace Emacs's lisp interpreter.  And if you want to
implement Emacs Lisp strings as Guile strings (which seems like the
most reasonable approach), then you need to choose a representation
for multi-lingual text in Guile strings which harmonizes well with
Emacs.

The way the winds are blowing, it looks like Unicode is eventually
going to take over the world.  GTk, for example, uses UTF-8.  However,
Emacs currently uses its own encoding for multilingual text, called
Emacs-Mule.  Emacs-Mule is completely different from UTF-8.  It's not
even possible to convert Emacs-Mule text to UTF-8 and back without
losing information.  However, Emacs is going to switch to UTF-8; the
folks doing the multilingual work expect it to take at least a year,
and perhaps longer.

So how can Guile prepare itself for the future (UTF-8) while still
meeting its immediate obligations (GNU Emacs)?

The key observation here is that, while UTF-8 and Emacs-Mule are very
different, actually, for all the properties you really care about when
writing C code, they are the same.  The differences can all be hidden
away happily in tables and converters you'd need anyway.

So, what I'm trying to present in mbapi.texi is an interface which you
can use to handle Guile text.  By an interface, I don't just mean
functions and types, but also a set of *valid assumptions* you can
make when you write your code.  It's a set of rules.  And if you
follow these rules, your code will work, without modification, on
either Emacs-Mule or UTF-8 text.  You just need to recompile.

I don't know whether mbapi.texi does an adequate job of explaining
these issues, and making the strategy clear.  I hope it does.

So my big plan was: use the interface described in mbapi.texi as both
the external interface that Guile's clients need to conform to, and
also internally, in Guile's code itself.  At first, Guile would use
Emacs-Mule, and Guile could be happily integrated into Emacs.  Then,
when Emacs switched to UTF-8, Guile would to.  And, with adequate
attention to the interface, this switch would be painless for almost
all Guile clients.

Of course, it should go without saying that Maciej is the one you need
to please, not me.  He decides whether your changes go in or not.  But
since Guile is a GNU project, Maciej is answerable to Stallman, and
Stallman sees Emacs as the driving application for Guile.