Re: I18N/M17N?

[Masao Uebayashi]

Hello, and sorry for tardiness.

> > Just a curiousity, but is there any plan that Guile to be I18N'ed, or
> > better M17N'ed? Or inporting MULE features from Emacs???
> 
> I was supposed to work on this, but I don't spend time on Guile any
> more (I need to resign as a maintainer), so I encourage anyone who's
> interested to pick up the ball here.  Read guile-core/doc/mbapi.texi.
> There's even some code, on a branch called jimb_mb_branch_1.

I'm not familiar with such an area (too), but this looks nice to
me. At least, I feel a bit happiness to see that Guile is not destined
to UTF-8 as Perl 6 or Python 2.

> In the long run, Guile is supposed to replace the Emacs Lisp
> interpreter in Emacs.  For that integration to work in a useful way,
> Guile strings and Emacs Lisp strings need to be the same objects, and
> in general, Guile and Emacs should follow the same M17N approach.

Fully agreed.

> Or at least, that used to be the consensus.  There are a bunch of (I
> suspect inevitably) controversial design decisions we made a while
> back which the current contributors to Guile don't like.  I don't know
> how that's going to be sorted out.

It would be nice that this consensus is documented somewhere.

> For example:
> 
> To avoid wasting space, you'd like to be clever about your
> representation of strings, so that users see the memory usage they've
> come to expect when dealing with ASCII text, but can work with
> non-ASCII text through the same old string functions they already
> know.  None of this `wide char variant' garbage.
(profound observations omitted)

Hmm, why didn't you mention Mule? Isn't it the consensus that adopting
Mule's internal encoding to Guile?

M

---
Masao Uebayashi <address@hidden>    --- We like raw eggs.