В: Почему lisp-interaction-mode
существует, и есть ли причины использовать его вместо emacs-lisp-mode
?
В руководстве говорится, что emacs-lisp-mode
и lisp-interaction-mode
они идентичны, за исключением того, что последний связывается C-j
с eval-print-last-sexp
. Кроме того, «все остальные команды в режиме Lisp Interaction такие же, как в режиме Emacs Lisp». Насколько я могу судить, только *scratch*
буфер использует последний режим.
Мне кажется странным, что существует целый режим, который отличается от другого только одной привязкой клавиш, поэтому я предполагаю, что мне не хватает какой-либо истории или контекста.
Так:
- Почему
lisp-interaction-mode
существует? - Не считая
C-j
привязки клавиш, есть ли обстоятельства, при которых это было бы предпочтительнееemacs-lisp-mode
? - Будут ли какие-нибудь неожиданные последствия для изменения
*scratch*
режима буфера наemacs-lisp-mode
?
Мотивация для этого вопроса заключается в том, что прямо сейчас я связываю ключи дважды (в двух режимах), чтобы мой *scratch*
буфер вел себя как буферы, посещающие *.el
файлы. Если нет практической причины держаться lisp-interaction-mode
, я просто (setq initial-major-mode 'emacs-lisp-mode)
покончу с этим.
*scratch*
.Ответы:
Если вы не ненавидите
C-j
поведение (и я уверен, что большинство авторов elisp считают его удобным), просто держите вещи такими, какие они есть.Определите ваши ключи для
lisp-mode-shared-map
вместо того, чтобы дублировать их для конкретных режимов клавиатуры.Все
lisp-mode-map
,emacs-lisp-mode-map
иlisp-interaction-mode-map
имеют вlisp-mode-shared-map
качестве родителя раскладки клавиатуры.источник
Новый производный режим дешев: он
lisp-interaction-mode
наследуетсяemacs-lisp-mode
, его реализация - всего дюжина строк кода или около того. Он отличаетсяemacs-lisp-mode
только следующими способами:С другой стороны, он делится своей таблицей сокращений с
emacs-lisp-mode
.Edit: как отметило @phils в своем ответе (которые видят), то раскладка из
emacs-lisp-mode
иlisp-interaction-mode
разделяет общий предок,lisp-mode-shared-map
. Поэтому нет причин дублировать сочетания клавиш - просто определите ихlisp-mode-shared-map
, и они будут применяться к обоим режимам (иlisp-mode
тоже, но это, вероятно, хорошо).Наиболее очевидным последствием будет то,
lisp-interaction-mode-hook
что больше не будет выполняться в*scratch*
буфере.источник
emacs-lisp-mode-hook
работаетlisp-interaction-mode
потому, что так работают производные режимы . У него есть другая таблица ключей, но оба режима elisp используют одну и ту же родительскую таблицу ключей (lisp-mode-shared-map
). У него есть отдельная таблица синтаксиса, но она идентична таблице родительского режима (потому что она зависит от родительского режима при настройке).FWIW, я использую
emacs-lisp-mode
в*scratch*
буфере сам. Если я хочу что-то оценить, я просто делаю C-x C-eс C-uпрефиксом, когда это необходимо. Я не вижу недостатков в этой практике.Относительно того, почему этот режим существует, это всего лишь несколько строк кода на языке LISP
elisp-mode.el
, и он был там как всегда , поэтому удаление его кажется бессмысленным.источник
C-j
связаннымnewline-and-indent
, но в наши дни, когда отступы происходят более автоматически, это больше не является серьезной проблемой. Так что, если бы я еще не сделал это изменение давно, я бы не стал беспокоиться об этом сейчас.*.el
файловый буфер.