Re: current idea

[Werner LEMBERG <wl@xxxxxxx>]

> I am much more concerned that having done all, the result will be
> totally (as opposed to nearly) unmaintainable. I was trying to say
> that a clean rewrite is probably overdue anyway, and in the end, it
> might just be quicker, especially since you can then separate most
> of the translation to the I/O interface during saves and restores,
> rather than doing it inside the bowels of the editor on the fly.

No `clean rewrite' necessary.  Basically, Unicode will be just be
another supported character set in Emacs.  The only difference is that
it will be handled with priority, and that other character sets can be
mapped onto it.

> Moreover, if internal code is canonical UTF-8, and not some
> historical (essentially) single-byte-oriented code, you will have
> the 1:n translator problem rather than what is essentially an n^2
> translator problem, the latter arising because the internal code is
> such a bad fit for everything.

I don't understand that.  Please give an example.

> A final point is that by hiving off the translators to I/O, you can
> delay writing many of them, since there are already some pretty
> reasonable UTF-8 <-> Encoding-X translators available that can
> probably be adapted as UN*X pipes.

This is a completely different problem.  Using a UTF-8-like buffer
representation is just for convenience, not a necessity.  As Markus
has shown recently in another mail, different (more compactt) schemes
would be possible also.  I just can repeat that this is completely
hidden from the user on the Lisp level.


    Werner
--
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/linux-utf8/