Dmitry Astapov wrote: : : AWN>> У тебя случайно не стоят одновременно Mule и non-Mule одной версии? : AWN> : Именно так. А на что это влияет? : AWN> Не живут. Или живут, но не всегда. : : AWN> Внешне выглядит, будто non-Mule начинает отвечать, что Mule у него : AWN> есть. Или Mule-пакеты подхватывает. Или еще что... Ради интереса : AWN> запусти : : AWN> (if (featurep 'mule) (message "mule exist") (message "non-Mule")) : AWN> Что он скажет? : non-Mule : : : AWN> Неплохо так же посмотреть на содержание переменной load-path -- есть : AWN> ли там что-нибудь про mule? : Нет, ничего нету. : : : AWN> Возможно, это "невыживание" можно вылечить собрав сначала non-Mule, а : AWN> потом после очистки всего (`make clean' недостаточно, нужно : AWN> что-нибудь помассивнее, возможно distclean, а еще надежнее снести и : AWN> распаковать заново) собирать Mule. Основная идея -- чтобы на этапе : AWN> dump'а в non-Mule не вошли Mule куски и наоборот (я склонен : AWN> рассматривать именно это, как причину "невыживания"). : Судя по том, что я вижу, этот пакет собирался именно так. По крайней мере, : non-mule собирается до mule. : Но откуда тогда non-Mule знал при -vanilla при Cyrillic_XXX??? Что-то тут концы с концами не сходяться! :-( Можно ожидать, что когда ответ на этот вопрос станет ясен, станет, если не ясно, то хотя бы понятнее все остальное. Я все-еще предполагаю, что это где-то намутили ребята из Debian при пакетировании. Тебе будет не слишком сложно собрать XEmacs non-Mule самому, причем той версии, какой у тебя в Mule варианте нет? -- Andrew W. Nosenko (awn(a)bcs.zp.ua) Фамильный призрак (c) Елена Носенко

DA> совершенно другие self-insert-command, а вот на f4 - DA> по-прежнему some-function. Как такое может быть? AM> Что значит "совершенно другие self-insert-command"? У них AM> другие 'ascii-character? DA> Угу. Совсем другие. Те самые, которые из iso8859-5 :( Это оттого, что твой переключатель клавиатурной раскладки посылает излишние сообщения (MappingNotify/MappingKeyboard). При обработке этого сообщения происходит (src/event-Xt.c): case MappingKeyboard: x_reset_key_mapping (d); break; Нужно избавиться от этого переключателя -- он неправильный (у меня это был xrus, сейчас я от него избавился). Нужно пользоваться чистым xkb (с правильным переключателем) или чистым xmodmap. Я не знаю, что произойдет, если удалить вышеуказанную строчку. --alexm

AWN>> У тебя случайно не стоят одновременно Mule и non-Mule одной версии? AWN> : Именно так. А на что это влияет? AWN> Не живут. Или живут, но не всегда. AWN> Внешне выглядит, будто non-Mule начинает отвечать, что Mule у него AWN> есть. Или Mule-пакеты подхватывает. Или еще что... Ради интереса AWN> запусти AWN> (if (featurep 'mule) (message "mule exist") (message "non-Mule")) AWN> Что он скажет? non-Mule AWN> Неплохо так же посмотреть на содержание переменной load-path -- есть AWN> ли там что-нибудь про mule? Нет, ничего нету. AWN> Возможно, это "невыживание" можно вылечить собрав сначала non-Mule, а AWN> потом после очистки всего (`make clean' недостаточно, нужно AWN> что-нибудь помассивнее, возможно distclean, а еще надежнее снести и AWN> распаковать заново) собирать Mule. Основная идея -- чтобы на этапе AWN> dump'а в non-Mule не вошли Mule куски и наоборот (я склонен AWN> рассматривать именно это, как причину "невыживания"). Судя по том, что я вижу, этот пакет собирался именно так. По крайней мере, non-mule собирается до mule. AWN> Проследи также, чтобы относящиеся к Mule пакеты (как-то mule-base, AWN> edict, egg-its, ...) ложились не в lib/xemacs/xemacs-packages/, а в AWN> lib/xemacs/mule-packages/ Да, лежат именно в mule-packages. AWN> Cyrillic_XXX : на-map-лены совершенно другие self-insert-command, а AWN> вот на f4 - : по-прежнему some-function. Как такое может быть? AWN> Значи Gnus их перемапил. Только не спрашивай меня как -- не знаю. AWN> Но рискну предположить -- не думаю, что Gnus настолько ненормален, AWN> чтобы специально мапить все подряд XKB'шные keysym'ы -- скорее в нем AWN> где-то крутится цикл от 128 до 256 и мапится по этим кодам. Для AWN> проверки я попробовал сказать на своем non-Mule 21.4.3 AWN> (global-set-key ?Ф 'tab-to-tab-stop) global-set-key не найден во всех исходниках /usr/share/xemacs21/packages/lisp/gnus/*.el. Или надо искать где-то еще? AWN> и подобного эффекта не достиг. Cyrillic_EF остался жить и работать AWN> сам по себе, а 'Ф' -- само по себе. Но, поскольку твой non-Mule AWN> чистым non-Mule не есть (как я подозреваю) -- возможно у тебя AWN> побочным эффектом будет переопределение и Cyrillic_EF тоже. Я в нескольких местах в gnus.el нашел suppress-keymap -- сейчас попробую, что будет без него ... AWN> Более того -- специально ради проверки запустил Gnus. У меня все AWN> Cyrillic_XXX на своих местах и именно те, которые надо. Что удивительно - после того, как "ломается" keymap в message-mode -- ломается global-keymap :( Как можно отследить того, кто его меняет? -- Dmitry Astapov //ADEpt (mail-to: adept(a)umc.com.ua)

Dmitry Astapov wrote: : : : AWN> Тогда как он (non-Mule) распознавал Cyrillic_XXX при -vanilla? : AWN> Причем не важно, правильно или нет -- он по идее вообще не знает про : AWN> них. : : AWN> У тебя случайно не стоят одновременно Mule и non-Mule одной версии? : Именно так. А на что это влияет? Не живут. Или живут, но не всегда. Внешне выглядит, будто non-Mule начинает отвечать, что Mule у него есть. Или Mule-пакеты подхватывает. Или еще что... Ради интереса запусти (if (featurep 'mule) (message "mule exist") (message "non-Mule")) Что он скажет? Неплохо так же посмотреть на содержание переменной load-path -- есть ли там что-нибудь про mule? Возможно, это "невыживание" можно вылечить собрав сначала non-Mule, а потом после очистки всего (`make clean' недостаточно, нужно что-нибудь помассивнее, возможно distclean, а еще надежнее снести и распаковать заново) собирать Mule. Основная идея -- чтобы на этапе dump'а в non-Mule не вошли Mule куски и наоборот (я склонен рассматривать именно это, как причину "невыживания"). Проследи также, чтобы относящиеся к Mule пакеты (как-то mule-base, edict, egg-its, ...) ложились не в lib/xemacs/xemacs-packages/, а в lib/xemacs/mule-packages/ : : AWN> : : У меня после апргрейда на 21.4.3 сплошные вилы :( : xemacs-nomule : AWN> нормально работает после (require 'ru-keys), но gnus : регулярно : AWN> переопределяет keymap и приходится в хуке делать (load-file : : AWN> 'ru-keys.el). Грустно :( : Кстати, объясните мне такую вещь: в init.el делается : (global-set-key [f4] 'some-function). В ru-keys.el делается global-set-key : на все Cyrillic_XXX. После запуска gnus-а нажимаешь кнопочку "a" и : пробуешь написать новое сообщение. Обнаруживаешь, что на все Cyrillic_XXX : на-map-лены совершенно другие self-insert-command, а вот на f4 - : по-прежнему some-function. Как такое может быть? Значи Gnus их перемапил. Только не спрашивай меня как -- не знаю. Но рискну предположить -- не думаю, что Gnus настолько ненормален, чтобы специально мапить все подряд XKB'шные keysym'ы -- скорее в нем где-то крутится цикл от 128 до 256 и мапится по этим кодам. Для проверки я попробовал сказать на своем non-Mule 21.4.3 (global-set-key ?Ф 'tab-to-tab-stop) и подобного эффекта не достиг. Cyrillic_EF остался жить и работать сам по себе, а 'Ф' -- само по себе. Но, поскольку твой non-Mule чистым non-Mule не есть (как я подозреваю) -- возможно у тебя побочным эффектом будет переопределение и Cyrillic_EF тоже. Более того -- специально ради проверки запустил Gnus. У меня все Cyrillic_XXX на своих местах и именно те, которые надо. -- Andrew W. Nosenko (awn(a)bcs.zp.ua) Фамильный призрак (c) Елена Носенко

AWN>> нормально работает после (require 'ru-keys), но gnus : регулярно AWN>> переопределяет keymap и приходится в хуке делать (load-file : AWN>> 'ru-keys.el). Грустно :( [skip] Я его поборол. Проблема - в message.el. Вот дифф: --- message.el.orig Fri Jul 27 12:44:24 2001 +++ message.el Fri Jul 27 14:05:00 2001 ＠＠ -1352,7 +1352,7 ＠＠ (unless message-mode-map (setq message-mode-map (make-keymap)) - (set-keymap-parent message-mode-map text-mode-map) + (set-keymap-parents message-mode-map (list text-mode-map (current-global-map))) (define-key message-mode-map "\C-c?" 'describe-mode) (define-key message-mode-map "\C-c\C-f\C-t" 'message-goto-to) Проблема в том, что в text-mode-map не определены Cyrillic_XXX -- он сам за ними ходит в global-map. Почему не происходит рекурсивный lookup -- я не знаю. Внимание, вопрос: как правильно пропихнуть это в upstream? -- Dmitry Astapov //ADEpt (mail-to: adept(a)umc.com.ua)

AWN> Тогда как он (non-Mule) распознавал Cyrillic_XXX при -vanilla? AWN> Причем не важно, правильно или нет -- он по идее вообще не знает про AWN> них. AWN> У тебя случайно не стоят одновременно Mule и non-Mule одной версии? Именно так. А на что это влияет? AWN> : : У меня после апргрейда на 21.4.3 сплошные вилы :( : xemacs-nomule AWN> нормально работает после (require 'ru-keys), но gnus : регулярно AWN> переопределяет keymap и приходится в хуке делать (load-file : AWN> 'ru-keys.el). Грустно :( Кстати, объясните мне такую вещь: в init.el делается (global-set-key [f4] 'some-function). В ru-keys.el делается global-set-key на все Cyrillic_XXX. После запуска gnus-а нажимаешь кнопочку "a" и пробуешь написать новое сообщение. Обнаруживаешь, что на все Cyrillic_XXX на-map-лены совершенно другие self-insert-command, а вот на f4 - по-прежнему some-function. Как такое может быть? -- Dmitry Astapov //ADEpt (mail-to: adept(a)umc.com.ua)

AM> <yawn> Читайте архивы списка рассылки. И что я должен был увидеть в списке рассылки? Совет о том, что нужно выставить set-charset-ccl-program? Так вопрос-то про non-mule xemacs. У меня после апргрейда на 21.4.3 сплошные вилы :( xemacs-nomule нормально работает после (require 'ru-keys), но gnus регулярно переопределяет keymap и приходится в хуке делать (load-file 'ru-keys.el). Грустно :( В xemacs-mule все в порядке со вводом и отображением, но gnus вместо русских букв показывает '~~~~' Подозреваю, что проблема в моем .gnus, но что именно там криво - сам вычислить не могу :( -- Dmitry Astapov //ADEpt (mail-to: adept(a)umc.com.ua)