[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Unicode Lisp reader escapes

From: Richard Stallman
Subject: Re: [PATCH] Unicode Lisp reader escapes
Date: Tue, 16 May 2006 23:45:26 -0400

    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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]