[Q21.5] Add support for non-ISO2022 8 bit fixed-width coding-systems.

[Stephen J. Turnbull]

(Moved from the XEmacs Patches thread with the same Subject.)

Aidan Kehoe writes:

 >  > Well, since this shouldn't actually be happening :-) (and in practice
 >  > is fairly unusual even for most European users, I believe),
 > 
 > No it’s not. http://mid.gmane.org/f2g834$sds$1@sea.gmane.org ,
 > http://mid.gmane.org/87ll1xcm3r.fsf@xemacs.org . I could trawl the
 > lists some more if you want.

My point here is about *performance* of an exception-based mechanism,
which (as with all issues about the performance of coding systems) is
that coding of text is a one-pass operation, and in almost all cases
the process of handling an exception is simply not going to cause
delay perceptible to a user.  If this stuff were happening thousands
of times a second in loops, I'd worry about it.

We need a more reliable and more maintainable coding system framework.
You've taken a step in that direction for Cyrillic, assuming that CCL
can be considered reliable and maintainable when there's only one
XEmacs developer who understands it at all.  But then you say similar
coding systems would be inappropriate for Latin scripts and advocate
that kludge latin-unity instead, except maybe for Greek.  Huh?

 > It would be appropriate to move iso-8859-7 to being this kind of
 > coding system, I think, since the Greeks don’t want ISO-2022
 > encoding either,

Nobody wants ISO 2022 extensions in any ISO 8859 coding systems AFAIK.

 > Mule-UCS was faster than the 21.5 utf-8 implementation for me in
 > practice--I’ve just double-checked this impression.

And would you like to explain your methodology so others can replicate
the experiment, and try to figure out where the slowness occurs?