Re: Q: something like autoload for coding-systems?

[Richard Stallman]

    > Anyway, if we use this only for the large Han-character coding
    > systems, it should not be very slow, and it will get big savings.

    ...

    For Emacs 21.1, we already preload all the chinese-based
    coding systems.  And, that preloading doesn't require much
    memory...

    But, for the future (Unicode-based) Emacs, of course, this
    is not true.

Yes, that's the motive behind looking at this idea.

                  I've just checked how big the interval list
    will be for GB2312 charset.  I tried to make a vector of the
    forms [ (FROM-CHAR . TO-CHAR) ... ], and to optimize, if
    FROM-CHAR == TO-CHAR, put FROM-CHAR in a element instead of
    cons.  Provided that each number consumes one word, and each
    cons consumes three words, the vector roughly consumes 6300
    words.  It's about 25K-byte.  It is surely smaller than the
    whole mapping table.

Can these codes fit in 16 bits?  If so, a special-purpose data type
could store it more densely.  We can live with 250k bytes for this,
but it would be worth some effort to cut that to 125k.

Depending on the patterns of coverage, other data types such as
bitmaps and run-length-encodings of bitmaps could provide more dense
representations, especially if they can be used for just parts of the
code space.

Another idea: instead of one table for each coding system, have a
common table for characters covered by all the Chinese coding systems,
and then a table of extra characters for each one.  Maybe this
would save further space.