[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 04 May 2001 23:35:30 +0900
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.
> 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?
Masao Uebayashi <address@hidden> --- We like raw eggs.
- Re: I18N/M17N?, Masao Uebayashi, 2001/05/03
- Re: I18N/M17N?,
Masao Uebayashi <=