>>>>> "DA" == Dmitry Astapov <adept(a)umc.com.ua> writes:
>>> После апгрейда на 21.4.3 я наблюдаю следующую ерунду - вводятся
>>> русские буквы, но неправильные - не в кодировке koi8-r, а в
>>> кодировке iso8859-5.
AM> <yawn> Читайте архивы списка рассылки.
DA> Мда. ПОглядел я на event-Xt.c ... Ну зачем было хардкодить туда
DA> iso8859-5?
Потому что для внутреннего представления кириллических символов в
XEmacs/Mule используется некая кодировка, один из байтов которой
совпадает с iso8859-5.
А что еще туда хардкодить? koi8-r нельзя, потому что koi8-r -- это
Russian, а iso8859-5 -- Cyrillic.
Тот массив, который ты видел (cyrillic[]), он по словам его автора
(martin(a)xemacs.org) _для Non-Mule_ является "very last resort" и
предполагается быть переопределенным в пакете типа ru-keys.
From: Martin Buchholz <martin(a)xemacs.org>
To: Alexey Mahotkin <alexm(a)hsys.msk.ru>
Cc: xemacs-beta(a)xemacs.org
Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs
Date: Thu, 10 May 2001 18:21:00 +0900
>>>>> "A" == Alexey Mahotkin <alexm(a)hsys.msk.ru> writes:
>>>>> "MB" == Martin Buchholz <martin(a)xemacs.org> writes:
MB> Oh, Alexey, can't you do everything you need for koi8 without
MB> hacking the C code, by doing simply:
MB> ;;; koi8.el: (when (not (featurep 'mule)) (keyboard-translate
MB> 'Cyrillic_hardsign 'ydiaeresis) ... )
A> I want to switch by whole arrays.
A> First reason: there is already code `x_keysym_to_character' that works
A> but just needs a clean well-defined hack to solve single simple
A> problem (Stephen, I consider your concerns about overcyrillization).
It would be easy to add some hack to allow the user to specify the
translation from keysym to equivalent character in event-Xt.c. This
can be implemented internally using a hash table. But I'm not all
sure that doing this is a good idea, since it adds Yet Another Key
Mapping Mechanism, when we already have so many. And I don't
understand why the ones we have (specifically, function-key-map) don't
do exactly what you want.
You have to maintain a mapping table from keysyms to koi8 character
codes in any case. Isn't it easier to have it in lisp code than C code?
A> Second reason, more practical about why I want to deal with arrays:
A> suppose we're setting cp1251 encoding for Cyrillic characters. We
A> have
A> (defun set-cyrillic-cp1251-encoding
A> (set-keysym-translation 'Cyrillic_HARDSIGN ?\xDA)
A> (set-keysym-translation 'Cyrillic_DZHE ?\0x8F))
A> After that we want to switch to koi8-r. We have:
A> (defun set-cyrillic-koi8-r-encoding
A> (set-keysym-translation 'Cyrillic_HARDSIGN ?\xFF)
A> ;; because koi8-r does not have DZHE
A> (set-keysym-translation 'Cyrillic_DZHE nil))
A> That is, we have to explicitly unset every keysym that could be
A> supported by some other encoding and could not be supported by the
A> encoding we're trying to set. This is very tedious IMHO and is better
A> handled by
A> char *cyrillic = cyrillic_koi8_r;
I disagree about "tedious". The information about keysyms which
should be mapped to nil has to be maintained in any case, so there is
just as much code to maintain. And I don't think humans will notice
the time taken by the computer to do the remappings.
I disagree that we should have a specific C-level mechanism for koi8.
The C code you are hacking in event-Xt.c is a fallback of last resort.
It could actually have been implemented by simply populating
global-map, but doing it in C the way we did was a small optimization
of space and startup time, and reduces user confusion by not having
global-map cluttered with key bindings for keys the user doesn't have.
DA> Почему бы не делать XLookupString для отыскания character по
DA> keysym???
--alexm
