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

[Stephen J. Turnbull]

Aidan Kehoe writes:

 >  > And what does
 >  > 
 >  >      (encode-coding-string (make-char 'japanese-jisx0208 48 108) 'koi8-r)
 >  > 
 >  > do? 
 > 
 > The right thing; it returns a string consisting of a tilde.

That's what our coding systems currently do, but that's the wrong
thing; it should throw an error, with the current state of the
encoding process available to condition-case.

 > It seems to me that an API like 
 > 
 > (query-coding-region START END CODING-SYSTEM &optional BUFFER)
 > 
 > returning, say, a list of buffer offsets and lengths, is the most
 > appropriate general way to implement a UI for warning that a given coding
 > system will not encode a given buffer.

Well, since this shouldn't actually be happening :-) (and in practice
is fairly unusual even for most European users, I believe), I think use of
a well-designed exception mechanism is to be preferred to explicit
tests (that most code will fail to do) in the long run.

 >  > Is there a reason why this technique should be restricted to coding
 >  > systems currently implemented in CCL, or could/should we replace all ISO
 >  > 8859 coding systems with this stuff?
 > 
 > Well, latin-unity deals with that problem for the 8859 coding systems, and
 > in a way that’s compatible with 21.4, so I don’t necessarily see any reason
 > to change that. 

Yeah, except latin-unity sucks for a lot of reasons you're aware of.
Including performance, not to mention UI, and charset coverage.

 >  >  > These coding systems are much faster than that implies.
 >  > 
 >  > I don't think it's worth worrying about speed of coding systems until
 >  > somebody complains.  AFAIK nobody's complained about the *speed* of
 >  > mule-ucs, so I doubt they'll complain about this either.
 > 
 > Spoken like a true Lisper :-) .

Please, I really don't need to deal with this kind of humor.  I
mentioned coding systems and Mule-UCS, I meant coding systems and
Mule-UCS.  XEmacs 21.5 has lots of speed issues in redisplay and
font-lock.  To the best of my knowledge, however, the only coding-
related code with efficiency problems at present is latin-unity.

Do you know anything to the contrary?