Re: [PATCH] Unicode Lisp reader escapes

[Richard Stallman]

    Well, as already mentioned, unification and fragmentation are
    implemented by means of translation tables. Unification, for instance,
    for non-CCL decodings happens by means of modifying the parent of the
    char table in the variable `standard-translation-table-for-decode'.

This suggests another implementation: make two such tables, one for
unification and one not for unification, and the mode can choose
which one gets used.

I'd like to understand a little more of the current design.  The
translation table that unification alters is the parent of the one in
`standard-translation-table-for-decode'.  What is the purpose of
making these child maps?

    I have no idea whether it is simple to make this variable buffer local
    or not. But, well, it's certainly intrusive to change such things at
    the very heart and core of Emacs' decoding/encoding apparatus.

This kind of change is not intrusive at all.  It ought to be pretty trivial.

    The translation table relevant for unification in CCL decoding is
    `ucs-translation-table-for-decode' (AFAICS only the cyrillic encodings
    make use of this). The translation table relevant for fragmentation of
    UCS coding systems is `utf-translation-table-for-decode'. You'd have
    to find a way to make *that* buffer local.

It looks very easy to make the choice of table dynamic
for the Cyrillic coding systems.

What does "fragmentation" mean?  I do not recall seeing that term
in this context.