- Implementation of fixed width 8,16,32 bit buffer representation
  optimization

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Implementing fixed-width buffer optimizations
=============================================

Add set-buffer-optimization (buffer &rest keywords) for
controlling these things.

Also, put in hack so that correct arglist can be retrieved by
Lisp code.

Look at the way keyword primitives are currently handled; make
sure it works and is documented, etc.

Implement 8-bit fixed width optimization.  Take the things that
know about the actual implementation and put them in a single .h
file, in essence creating an abstraction layer to allow
pluggable internal representations.  Implement a fairly general
scheme for mapping between character codes in the 8 bits or 16
bits representation and on actual charset characters.  As part of
set-buffer-optimization, you can specify a list of character sets
to be used in the 8 bit to 16 bit, etc. world.  You can also
request that the buffer be in 8, 16, etc. if possible.

-> set defaults wrt this.
-> perhaps this should be just buffer properties.
-> this brings up the idea of default properties on an object.
-> Implement default-put, default-get, etc.

What happens when a character not assigned in the range gets
added?  Then, must convert to variable width of some sort.

Note: at first, possibly we just convert whole hog to get things
right.  Then we'd have to pay attention to characters that got
added + deleted that were unassigned in the fixed width.  When
this goes to zero and there's been enough time (heuristics), we
go back to fixed.

Side note:  We could dynamically build up the set of assigned
chars as they go.  Conceivably this could even go down to the
single char level: Just keep a big array of mapping from 16 bit
values to chars, and add each time, a char has been encountered
that wasn't there before.  Problem: need inverse mapping.

-> Possibility; chars are actual objects, not just numbers.
Then you could keep track of such info in the char itself.
*Think about this.*

Eventually, we might consider allowing mixed fixed-width,
variable-width buffer encodings.  Then, we use range tables to
indicate which sections are fixed and which variable and INC_CHAR does
something like this: binary search to find the current range, which
indicates whether it's fixed or variable, and tells us what the
increment is.  We can cache this info and use it next time to speed
up.

-> We will then have two partially shared range tables - one for
overall fixed width vs. variable width, and possibly one containing
this same info, but partitioning the variable width more.  Maybe
need fancier nested range table model.