После переезда с 23-ей на 24-ю версию перестали открываться документы в формате docbook с ошибкой: byte-code: Cannot open load file: rfc2047 При этом сам файл открывался, но на первом плане оставался буфер *scratch*. Помогало или отодвигание конфигов (но какого именно пункта так и не нашел), либо удаление файла /usr/share/emacs/24.1/lisp/mail/sendmail.elc Пример файла (ch_intro.xml): <chapter id="ch_intro"> <title>Введение</title> <para> Тест. </para> </chapter>
Проверьте, что установлен пакет emacs24-gnus. Если есть, желателен также лог обновления (какие пакеты удалены/установлены/обновлены).
(В ответ на комментарий №1) > Проверьте, что установлен пакет emacs24-gnus. пакет установлен не был, его установка (с предварительным 'apt-get install --reinstall emacs24-common', т.к. я удалял файл sendmail.elc) проблему решила.
Без лога обновления сложно сказать, почему emacs23-gnus не обновился до emacs24-gnus. В моих тестах это обновление прошло гладко.
(В ответ на комментарий №3) > Без лога обновления сложно сказать, почему emacs23-gnus не обновился до > emacs24-gnus. В моих тестах это обновление прошло гладко. не обновился он наверняка потому, что и не был установлен. :) разве не есть проблема то, что что-то не требующее emacs2x-gnus явно, требует его по факту при определенных обстоятельствах? а лог обновления приложил, он правда большой...
Created attachment 5523 [details] лог обновления
В этом логе нет ничего, касающегося обновления emacs. Если пакет не был установлен, то нет причин жаловаться, что он не работает после обновления. Неясно правда, как тогда что-то работало, но это уж вам виднее. Да, это проблема. В своё время, в 2008-м, я делал подход к её решению в пакете rpm-build-emacs (см. у меня в git). Идея была в том, чтобы на этапе сборки rpm-пакета выяснять зависимости и перекладывать на rpm/apt заботу об их удовлетворении. Это работало, но результат получился неутешительный: либо мы б.м. сохраняем мелкую нарезку на подпакеты и правим огромное количество elisp-кода (как в emacs, так и в сторонних пакетах) либо пакуем emacs одним большим пакетом и тоже правим много elisp-кода, так как он, исторически, пишется без учёта таких вот моментов с зависимостями. В итоге, проще оказалось сохранить статус кво и запастись советами "Установите пакет emacsXX-YYY".
(В ответ на комментарий №6) > Да, это проблема. В своё время, в 2008-м, я делал подход к её решению в пакете > rpm-build-emacs (см. у меня в git). Идея была в том, чтобы на этапе сборки > rpm-пакета выяснять зависимости и перекладывать на rpm/apt заботу об их > удовлетворении. Это работало, но результат получился неутешительный: либо мы > б.м. сохраняем мелкую нарезку на подпакеты и правим огромное количество > elisp-кода (как в emacs, так и в сторонних пакетах) либо пакуем emacs одним > большим пакетом и тоже правим много elisp-кода, так как он, исторически, > пишется без учёта таких вот моментов с зависимостями. > > В итоге, проще оказалось сохранить статус кво и запастись советами "Установите > пакет emacsXX-YYY". понятно, спасибо за совет и emacs. :)
