Если вы наберете не ту команду Emacs, которую имели в виду, то последствия этого могут быть непонятны для вас. Эта глава рассказывает о том, что вы можете сделать для того, чтобы отменить вашу ошибку и выйти из непонятной ситуации. Здесь также рассматриваются сбои в Emacs и аварийные завершения.
abort-recursive-edit).
keyboard-escape-quit).
undo).
Существует два способа отмены команд, выполнение которых не закончилось: выход с помощью С-g и прерывание с помощью C-] или M-x top-level. Выход отменяет частично набранную команду или команду, которая уже выполняется. Прерывание выходит из одного уровня рекурсивного редактирования и отменяет команду, которая запустила это рекурсивное редактирование. (Смотрите раздел Уровни рекурсивного редактирования.)
Выход с помощью C-g используется для того, чтобы освободиться от частично набранной команды или числового аргумента, который вам не нужен. Она также относительно безопасно останавливает выполнение уже работающей команды, так что вы можете использовать ее, если случайно зададите команду, требующей много времени. В частности, выход из уничтожения безопасен; либо ваш текст полностью останется в буфере, либо полностью попадет в список уничтожений (или будет и там, и там). Выход из наращиваемого поиска выполняет специальные действия, документированные отдельно; в общем случае, чтобы выйти из поиска, может потребоваться два последовательных C-g (смотрите раздел Наращиваемый поиск).
В MS-DOS клавишей выхода, подобной C-g, служит C-BREAK. Так сделано по той причине, что в MS-DOS невозможно зарегистрировать нажатие C-g во время работы команды между интеракциями с пользователем. Напротив, зарегистрировать C-BREAK можно всегда. Смотрите раздел Клавиатура и мышь в MS-DOS.
Работа C-g заключается в установке переменной quit-flag в
значение t, как только C-g был набран; Emacs Lisp часто
проверяет эту переменную и выходит, если она не равна nil.
С-g действительно выполняется как команда, только если вы набирали
ее в то время, когда Emacs ожидает ввода.
Если вы выйдите с помощью С-g второй раз до того, как первая C-g была опознана, то вы активизируете средство "аварийного выхода" и возвращаетесь в оболочку. Смотрите раздел Аварийный выход.
Бывает много случаев, когда вы не сможете выйти. Когда Emacs ожидает, пока операционная система завершит какое-нибудь действие, выход невозможен, если только не предприняты особые меры для некоторых системных вызовов из Emacs, где случается ожидание. Мы предприняли эти меры для тех системных вызовов, из которых пользователи, вероятно, захотят выходить, но может случиться, что вы найдете еще один. В одном очень распространенном случае, при ожидании ввода или вывода файла с использованием NFS, сам Emacs знает, как выйти, но большинство реализаций NFS просто не позволяют пользовательским программам прекратить ожидание NFS, когда NFS-сервер завис.
Прерывание с помощью C-] (abort-recursive-edit)
используется для того, чтобы выйти из одного уровня рекурсивного
редактирования и отменить команду, которая его запустила. Выход с
помощью C-g не делает этого и не может этого делать, потому что он
используется для отмены частично набранной команды внутри
текущего уровня рекурсивного редактирования. Обе эти операции полезны.
Например, если вы находитесь в рекурсивном редактировании и набираете
C-u 8, чтобы ввести числовой аргумент, то вы можете отменить этот
аргумент с помощью C-g и остаться в рекурсивном редактировании.
Команда ESC ESC ESC
(keyboard-escape-quit) может совершить и выход, и прерывание.
Этот ключ был определен, потому что во многих программах для PC для
"выхода" используется ESC. Он может отменить числовой аргумент,
очистить выделенную область или выйти из замены с подтверждением, как
C-g. Он также может прервать работу минибуфера или одного уровня
рекурсивного редактирования, как C-]. Он также может отменить
разбиение фрейма на несколько окон, как C-x 1. Единственное, что
он не может сделать -- остановить работающую команду. Причина этого в
том, что этот ключ выполняется как обыкновенная команда, и Emacs не
замечает ее, пока не будет готов принять новую команду.
Команда M-x top-level эквивалентна "достаточному количеству" команд C-], чтобы прервать все уровни рекурсивного редактирования, в которых вы находитесь. C-] дает вам возможность покинуть один уровень за один раз, а M-x top-level покидает все уровни сразу. Как C-], так и M-x top-level похожи на все другие команды и не похожи на C-g тем, что они действуют, только когда Emacs готов для приема команды. C-] -- обыкновенный ключ и имеет смысл только благодаря привязке в таблице ключей. Смотрите раздел Уровни рекурсивного редактирования.
C-x u (undo), строго говоря, не является способом отмены
команды, но вы можете представлять ее как отмену команды, уже окончившей
выполнение. Смотрите раздел Отмена сделанных изменений.
Этот раздел описывает различные условия, при которых Emacs отказывается работать правильно, и рассказывает, как распознать и исправить проблемы.
Если вы обнаружили, что DEL выдает справку, как Control-h, а не удаляет знак, это значит, что ваш терминал посылает неверный код для DEL. Вы можете справиться с этой проблемой, изменив таблицу преобразования клавиатуры (смотрите раздел Перевод клавиатуры).
Уровни рекурсивного редактирования являются важным и полезным средством Emacs, но тем пользователям, кто их не понимает, они могут показаться сбоем в работе Emacs.
Если в строке режима вокруг круглых скобок есть квадратные скобки `[...]', которые содержат имена главного и второстепенных режимов, то это означает, что вы вошли в уровень рекурсивного редактирования. Если вы не хотели этого или не понимаете, что это значит, то вы должны просто покинуть этот уровень рекурсивного редактирования. Чтобы это сделать, наберите M-x top-level. Это называется возвратом к верхнему уровню. Смотрите раздел Уровни рекурсивного редактирования.
Если данные на экране выглядят неправильно, то первое, что надо сделать, -- посмотреть, действительно ли текст неправилен. Наберите C-l, чтобы весь экран полностью перерисовался. Если он после этого появится в правильном виде, то неисправность была в предыдущем обновлении экрана. (Если нет, смотрите раздел Мусор в тексте.)
Проблемы с обновлением изображения часто возникают из-за неправильной записи termcap для используемого вами терминала. Файл `etc/TERMS' в дистрибутиве Emacs содержит исправления для известных проблем такого рода. `INSTALL' содержит в одном из своих разделов общие рекомендации по этим проблемам. Весьма вероятно, что просто недостаточно наполнение некоторых операций отображения. Чтобы проверить, не этого ли сорта у вас проблема, попробуйте запустить Emacs на другом терминале, сделанном другим производителем. Если неполадки обычно случаются на определенном виде терминалов, а на других нет, то это происходит, вероятно, из-за неправильной записи в termcap, хотя это также может быть результатом ошибки в Emacs, которая появляется на терминалах с какими-то особенностями или которым не хватает специфических средств.
Если C-l показывает, что текст неправильный, попробуйте отменить в нем изменения, используя C-x u до тех пор, пока она не вернет текст к состоянию, которое вы считаете правильным. Кроме того, попробуйте C-h l, чтобы найти команду, набор которой привел к замеченным результатам.
Если кажется, что в начале или конце буфера пропал большой кусок текста, проверьте наличие слова `Narrow' в строке режима. Если оно там есть, то текст все еще присутствует в буфере, но он помечен как выходящий за границы доступности. Чтобы сделать его вновь видимым, наберите C-x n w. Смотрите раздел Сужение.
Если Emacs самопроизвольно показывает `I-search:' внизу экрана, то это означает, что терминал посылает C-s и C-q из-за плохо разработанного протокола управления потоком данных типа xon/xoff.
Если это с вами случилось, лучшим выходом будет постараться установить
терминал в такой режим, где он не будет использовать управление потоком
данных, или давая ему достаточное заполнение, чтобы он никогда не
посылал C-s. (Один из способов увеличить величину заполнения ---
присвоить переменной baud-rate большее значение. Значение этой
переменной обозначает скорость вывода терминала, выраженную в обычных
единицах, бодах.)
Если вам не удалось выключить управление потоком, тогда лучше всего
будет сказать Emacs справиться с ним самому. Чтобы сделать это,
вызовите функцию enable-flow-control.
Как правило, встречаются определенные типы терминалов, на которых вы
вынуждены использовать управление потоком. Используя
enable-flow-control-on, вы можете удобно запросить использование
управления потоком только для этих типов терминалов. Например, если вы
обнаружили, что должны использовать управление потоком на терминалах
VT-100 и H19, поместите в ваш файл `.emacs' следующее:
(enable-flow-control-on "vt100" "h19")
Когда задействовано управление потоком, вы должны набирать C-\, чтобы получить результат C-s, и C-^, чтобы получить результат C-q. (Эти псевдонимы работают посредством преобразований клавиатуры; смотрите раздел Перевод клавиатуры.)
Если вы получили сообщение `Virtual memory exceeded'(14), сохраните измененные буферы командой C-x s. Этот способ сохранения буферов требует минимальное количество дополнительной памяти. Emacs хранит резерв памяти, которая становится доступна, когда возникает эта ошибка; его должно быть достаточно, чтобы C-x s могла завершить свою работу.
Как только вы сохранили измененные буферы, вы можете выйти из этого задания Emacs и начать другое или воспользоваться командой M-x kill-some-buffers, чтобы освободить пространство для текущего задания Emacs. Если вы уничтожите буферы, содержащие значительный объем текста, вы сможете безопасно продолжать редактирование. Emacs заново резервирует память автоматически, когда видит, что доступно достаточно свободного места, на случай, если память опять закончится.
Не используйте M-x buffer-menu, чтобы сохранить или уничтожить буферы, когда вы исчерпали память, потому что меню буферов само требует заметного количества памяти, и резерва может не хватить.
Если в Emacs или компьютере произошел фатальный сбой, вы можете восстановить файлы, которые вы редактировали в момент краха, из их автоматически сохраненных версий. Чтобы сделать это, запустите Emacs снова и наберите команду M-x recover-session.
Сначала эта команда покажет буфер, перечисляющий файлы прерванных сеансов, каждый со своей датой. Вы должны выбрать сеанс, который вы хотите восстановить. Обычно это самый последний. Переместите точку к выбранному файлу и введите C-c C-c.
Затем recover-session спросит вас о каждом файле, который вы
редактировали во время того сеанса; она спрашивает, нужно ли
восстанавливать этот файл. Если вы отвечаете y для какого-нибудь
файла, она показывает даты этого файла и его автоматически сохраненной
версии и снова спрашивает, нужно ли его восстанавливать. Этот второй
запрос вы должны подтверждать вводом yes. Если вы это сделаете,
Emacs обращается к этому файлу, но берет текст из самосохраненного
файла.
Когда recover-session завершает работу, выбранные вами файлы
находятся в буферах Emacs. Теперь вы должны их сохранить. Только это
--- их запись -- обновляет сами файлы.
Так как в свое время были ошибки, вызывавшие зацикливание Emacs без
проверки quit-flag, было введено специальное средство, которое
заставляет Emacs немедленно прерваться, если вы наберете второй
C-g, когда флаг уже установлен. Таким образом, вы всегда можете
покинуть GNU Emacs. Обычно Emacs опознает и очищает quit-flag (и
выходит!) достаточно быстро, чтобы этого не случалось. (В MS-DOS и
совместимых системах набирайте дважды C-BREAK.)
Когда вы возвращаетесь в Emacs после прерывания, вызванного
множественными C-g, он задает два вопроса, перед тем как вернуться
к тому, чем он был занят:
Auto-save? (y or n)
Abort (and dump core)? (y or n)
Отвечайте на каждый из них y или n и последующим RET.
Ответ y на `Auto-save?' вызывает немедленную автоматическую запись всех модифицированных буферов, в которых включено автоматическое сохранение.
Ответ y на `Abort (and dump core)?' приводит к выполнению
недопустимой инструкции и сбросу дампа памяти. Это нужно, чтобы дать
возможность специалисту понять, почему Emacs не выполнил выход в первый
раз. После сброса дампа памяти выполнение не продолжается. Если вы
ответите n, выполнение продолжится. Если повезет, GNU Emacs в
конечном счете проверит quit-flag и выйдет обычным образом. Если
нет, и вы наберете другую С-g, он прервется снова.
Если Emacs на самом деле не завис, а просто медленно работает, вы можете вызвать действие двойного C-g, не желая этого в действительности. Тогда просто возобновите работу Emacs и ответьте n на оба вопроса, и вы попадете в прежнее состояние. Вероятно, затребованный вами выход скоро произойдет.
Средство двойного C-g отключено, когда Emacs запускается в системе X Windows, поскольку программа управления окнами всегда дает вам возможность уничтожить Emacs или создать другое окно и запустить другую программу.
В MS-DOS и совместимых системах аварийный выход иногда невозможен, даже если вы нажимаете C-BREAK дважды, когда зависает какой-то системный вызов (MS-DOS или BIOS), или когда Emacs попал в очень короткий бесконечный цикл (в коде на Си, не на Лиспе).
Если использование Emacs (или что-нибудь еще) страшно вас расстраивает и никакие методы, описанные выше, не решают проблему, то Emacs все еще может вам помочь.
Во-первых, если ваш Emacs не отвечает на команды, наберите C-g C-g, чтобы выйти из него и запустить новый.
Во-вторых, наберите M-x doctor RET.
Доктор поможет вам, и вы почувствуете себя лучше. Каждый раз, когда вы что-нибудь говорите доктору, вы должны оканчивать это набором RET RET. Это позволит доктору узнать, что вы закончили.
Иногда вы будете сталкиваться с ошибками в Emacs. Хотя мы не можем обещать, что можем или будем исправлять ошибки, мы можем даже не согласиться, что это ошибка, но мы все равно хотим услышать о проблемах, с которыми вы столкнулись. Часто мы соглашаемся, что это ошибки, и хотим их исправить.
Чтобы дать нам возможность исправить ошибку, вы должны описать ее. Чтобы сделать это эффективно, вы должны знать когда и как это делать.
Если Emacs выполняет недопустимую инструкцию или прерывается с сообщением операционной системы об ошибке, которая указывает на неполадку в программе (в противоположность чему-нибудь вроде "нет места на диске"), то это определенно ошибка в Emacs.
Если Emacs обновляет изображение так, что оно не соответствует тому, что находится в буфере, то это определенно ошибка. Если похоже, что команда выполняет ошибочные действия, но неполадка исправляется сама, если вы наберете C-l, то это случай неправильного обновления изображения.
Бесконечное ожидание завершения команды может быть ошибкой, но вы должны точно определить, что это действительно происходит по вине Emacs. Некоторые команды просто требуют много времени. Наберите C-g (C-BREAK в MS-DOS) и затем C-h l, чтобы увидеть, получил ли Emacs тот ввод, какой вы хотели набрать. Если ввод был таким, о котором вы знаете, что он должен обрабатываться быстро, сообщайте об ошибке. Если вы не знаете, должна ли эта команда требовать много времени, выясните это, либо просмотрев руководство, либо попросив помощи.
Если команда, с которой вы хорошо знакомы, выдает сообщение об ошибке там, где ее обычное определение должно быть правильным, то это, вероятнее всего, ошибка.
Если команда выполняет неправильные действия, то это ошибка. Но чтобы быть уверенным, вы должны знать точно, что она должна была сделать. Если вы не очень хорошо знакомы с этой командой или не знаете наверняка, как она должна действовать, может оказаться, что в действительности она работает правильно. Прежде чем делать поспешный вывод, покажите вашу проблему тому, кто знает точно.
Наконец, предполагаемое определение команды может не быть лучшим способом редактирования. Это очень важная проблема, но это также вопрос точки зрения. Кроме того, можно легко прийти к такому заключению из-за незнания некоторых существующих возможностей. Скорее всего, лучше не жаловаться на неполадку до тех пор, пока вы не проверили как обычно документацию, не почувствовали, что разобрались до конца и знаете наверняка, что то, что вы хотите, недоступно. Если после внимательного прочтения руководства вы не уверены том, что должна делать команда, посмотрите предметный указатель и глоссарий для любого термина, который может быть неясен.
Если и после подробного прочтения руководства вы не поняли, что должна делать эта команда, то это указывает на ошибку в руководстве, о которой нужно сообщить. Задача руководства -- прояснить все для неэкспертов в Emacs, включая вас. Сообщать об ошибках в документации так же важно, так и об ошибках в программе.
Если диалоговая строка документации функции или переменной не согласуется с руководством, то одно из них неправильно; опишите это как ошибку.
Когда вы решите, что действительно нашли ошибку, то важно сообщить о ней и сделать это таким образом, чтобы описание было полезным. Что особенно полезно, так это точное описание команд, которые вы набирали, начиная с команды оболочки для запуска Emacs и вплоть до возникновения ошибки.
Самый важный принцип при сообщении об ошибках -- сообщать факты. Гипотезы и словесные описания не могут заменить простые подробные данные. Всегда легче описывать факты, но многие предпочитают постараться дать толкования и описать их вместо фактов. Если объяснения основывается на догадках о том, каким образом реализован Emacs, они будут бесполезны. Как правило, не располагая фактами, мы не будем иметь настоящей информации об ошибке.
Предположим например, что вы набираете C-x C-f /glorp/baz.ugh RET, обращаясь к файлу, который (как вы знаете) оказывается довольно большим, и Emacs печатает `Сегодня я себя прекрасно чувствую'. Наилучший способ описать эту ошибку -- привести предложение, подобное предыдущему, так как это дает все факты.
Не считайте, что неполадка возникла из-за размера файла, и не говорите: "Когда я обращаюсь к большому файлу, Emacs печатает `Сегодня я себя прекрасно чувствую'". Это именно то, что мы называем "объяснением на догадках". Настолько же возможно, что ошибка произошла из-за того, что в имени файла имеется `z'. Если это так, то когда мы получили бы ваше описание, мы пытались бы решить проблему с "большим файлом", вероятно, без `z' в его имени и не нашли бы никакой ошибки. Мы никак не могли бы догадаться, что должны были попробовать обратиться к файлу с буквой `z' в имени.
С другой стороны, ошибка могла возникнуть из-за того, что файл начинается точно с 25 пробелов. Поэтому вы должны убедится в том, что проинформировали нас о точном содержании любого файла, который потребуется, чтобы воспроизвести ошибку. Что если ошибка встречается только тогда, когда вы до того набрали команду C-x C-a? Вот почему мы просим вас давать точную последовательность знаков, которые вы набрали со времени запуска Emacs.
Вы не должны даже говорить "обратиться к файлу" вместо C-x C-f, если не уверены, что нет различий в том, какая команда обращения используется. Аналогично, лучше сказать "после того как я набираю RET A B C RET C-p", чем говорить "если у меня есть три буквы на строке", если вы ввели текст именно таким способом.
Поэтому, пожалуйста, не предполагайте объяснения, когда сообщаете об ошибке. Если в действительности вы хотите исследовать эту проблему в отладчике и сообщить объяснения, которые уже есть нечто большее, чем догадки, это будет нам полезно -- но пожалуйста, сообщите также и факты.
Лучший способ сообщить об ошибке -- отправить электронное письмо сопроводителям Emacs по адресу bug-gnu-emacs@gnu.org. (Если вы хотите предложить изменение или улучшение, используйте этот же адрес.)
Если вы хотите читать отчеты об ошибках, вы можете найти их в группе новостей `gnu.emacs.bug'; помните однако, что как наблюдатель вы не должны критиковать ничего из того, что вы там увидите. Цель сообщений об ошибках -- давать информацию сопроводителям Emacs. Наблюдатели приветствуются до тех пор, пока они не вмешиваются в это. В частности, некоторые отчеты содержат большие объемы данных; наблюдатели не должны на это жаловаться.
Пожалуйста, не посылайте сообщения об ошибках через сетевые новости; почта более надежна тем, что дает ваш точный адрес, который может понадобиться, чтобы попросить у вас больше информации.
Если вы не можете послать электронную почту, оправьте отчет об ошибке
на бумаге или на машинночитаемом носителе по следующему адресу:
GNU Emacs Bugs
Free Software Foundation
59 Temple Place, Suite 330
Boston, MA 02111-1307 USA
Мы не обещаем исправить ошибку; но если ошибка серьезная, или ужасная, или ее легко исправить, то вероятнее всего мы захотим это сделать.
Удобный способ послать отчет об ошибке в Emacs -- использовать команду M-x report-emacs-bug. Она подготавливает буфер сообщения (смотрите раздел Посылка почты) и автоматически вставляет некоторую важную информацию. Однако, она не может предоставить всю необходимую информацию; вы все равно должны прочитать приведенные ниже рекомендации и следовать им, тогда вы можете ввести остальные нужные сведения вручную перед отправкой сообщения.
Чтобы сопроводители могли исследовать ошибку, ваш отчет должен включать все следующие сведения:
configure во время установки Emacs.
(open-dribble-file "~/dribble")
используя M-: или из буфера `*scratch*' сразу после старта
Emacs. С этого момента Emacs копирует весь ваш ввод в указанный файл
сопровождения, пока процесс Emacs не будет уничтожен.
(open-termscript "~/termscript")
используя M-: или из буфера `*scratch*' сразу после старта
Emacs. С этого момента Emacs копирует весь терминальный вывод также и в
заданный файл терминального протокола до тех пор, пока процесс Emacs не
будет уничтожен. Если ошибка произошла в процессе запуска Emacs,
поместите это выражение в ваш файл `.emacs', таким образом, файл
терминального протокола будет открываться, когда Emacs отобразит экран в
первый раз.
Следует предупредить: часто трудно, а иногда и невозможно исправить
ошибку, зависящую от терминала, без доступа к терминалу того типа,
который эту ошибку порождает.
(setq debug-on-error t) перед тем, как произойдет ошибка (то есть
вы должны выполнить это выражение, а потом повторить ситуацию,
приводящую к ошибке). При возникновении ошибки это вызывает запуск
отладчика Лиспа, который покажет вам след. Скопируйте текст следа
отладчика в описание ошибки.
Такое использование отладчика возможно только в том случае, если вы
знаете, как вызвать ошибку снова. Если вы не можете воспроизвести ее,
по крайней мере скопируйте полное сообщение об ошибке.
-q, это предотвратит
загрузку файла инициализации). Если в этом случае ошибка не
встретится, вы должны сообщить точное содержание всех программ, которые
вы должны загрузить в среду Лиспа для того, чтобы заставить ошибку
проявиться.
pr, которая напечатает лисповский объект в синтаксисе
Лиспа. (Если вам приходится использовать другой отладчик, вызовите
функцию debug_print с этим объектом в качестве аргумента.)
Команда pr определена в файле `.gdbinit' и работает, только
если вы отлаживаете запущенный процесс (не дамп памяти).
Чтобы ошибка в Лиспе останавливала Emacs и возвращала в GDB, установите
контрольную точку в Fsignal.
Чтобы получить краткий список выполняющихся в данный момент лисповских
функций, наберите команду GDB xbacktrace.
Если вы хотите исследовать аргументы лисповских функций, переходите
вверх по стеку и каждый раз, когда попадаете во фрейм функции
Ffuncall, вводите такие команды GDB:
p *args
pr
Чтобы напечатать первый аргумент, полученный этой функцией, используйте
эти команды:
p args[1]
pr
Другие аргументы вы можете напечатать подобным же образом. Аргумент
nargs функции Ffuncall говорит, сколько аргументов
получила Ffuncall; это включает саму лисповскую функцию и ее
аргументы.
Файл `.gdbinit' определяет другие команды, полезные для просмотра
типов и содержимого лисповских объектов. Их имена начинаются с
`x'. Эти команды работают на более низком уровне, чем pr, и
менее удобны, но они могут работать, даже когда pr не работает,
например при отладке дампа памяти, или когда Emacs получил фатальный
сигнал.
Вот некоторые вещи, которые необязательны в отчете об ошибке:
pr (смотрите выше).
Если хотите написать исправления ошибок или улучшения для GNU Emacs, это очень нам поможет. Когда вы посылаете ваши изменения, пожалуйста, следуйте этим рекомендациям, чтобы сопроводителям было легче их использовать. Если вы не следуете им, ваши изменения тем не менее могут быть полезны, но использование их потребует дополнительной работы. Сопровождение GNU Emacs -- это в лучших обстоятельствах много работы, и нам будет трудно справляться, если вы не сделаете все от вас зависящее, чтобы нам помочь.
Если вы хотели бы помочь в тестировании выпусков Emacs, чтобы убедиться,
что они работают правильно, или если вы хотели бы работать над
улучшением Emacs, пожалуйста, свяжитесь с сопроводителями по адресу
bug-gnu-emacs@gnu.org. Испытатель должен быть готов как к
исследованию ошибок, так и к их описанию. Если вы желаете улучшить
Emacs, пожалуйста, спросите о предлагающихся проектах или предложите
свои идеи.
Если вы уже написали расширение, пожалуйста, сообщите нам об этом. Если
вы еще не начали работу, будет полезным связаться с
bug-gnu-emacs@gnu.org до того, как вы начнете; тогда мы сможем
посоветовать, как сделать так, чтобы ваши расширения лучше стыковались с
остальной частью Emacs.
Если вы нуждаетесь в помощи по установке, использованию или модификации GNU Emacs, у вас есть два способа получить ее:
gnu.emacs.help. (Этот
список рассылки и группа новостей сообщаются между собой, поэтому
безразлично, что именно вы будете использовать.)