Подтвердить что ты не робот

Как найти ошибку в ".emacs" или "init.el"?

Иногда, когда я открываю Emacs, инициализация Emacs терпит неудачу.
Это связано с тем, что файлы .emacs или init.el имеют ошибку. (Мои ошибки часто возникают из-за туманности.)

Я хочу найти ошибку в .emacs или init.el. Есть ли способ сделать это?

4b9b3361

Ответ 1

Чтобы узнать, какая часть вашего файла инициализации (~/.emacs) вызывает поведение, которое вы видите, bisect ваш файл инициализации рекурсивно: первая половина комментария, чтобы увидеть, какая половина отвечает, а затем 3/4, чтобы узнать, в какой из них отвечает,...

Чтобы прокомментировать область текста (например, последовательность строк, которые вы выбрали), я рекомендую comment-region (который я привязываю к C-x C-;). При использовании числового префикса arg он использует много символов комментария ;. При использовании простого префикса arg (C-u) он отменяет область, а не комментирует ее.

Вы также можете запустить Emacs с помощью командной строки --debug-init. Это приведет к тому, что отладчик откроется при возникновении ошибки во время запуска Emacs, в том числе во время загрузки файла инициализации. Вывод отладчика говорит вам, какая оценка вызвала ошибку (какая функция была вызвана), и она показывает вам, какая функция называется функцией, в которой была поднята ошибка, какая функция называла ее и т.д.

Когда вы знаете, какая функция является проблемой, если вам нужно, вы можете отладить ее оценку, поставив (debug-on-entry 'THE-FUNCTION) рядом с началом вашего файла инициализации. Это откроет отладчик, когда функция будет введена, а не просто покажет, что произошло при возникновении ошибки. Затем вы можете пройти через отладчик, используя d (или c, чтобы пропустить шаг), чтобы увидеть, что пошло не так.

Если вы хотите перейти к функции, начинающейся с некоторой точки останова, скопируйте исходный код, который определяет функцию в ваш файл инициализации, и вставьте (debug) в том месте, где вы хотите, чтобы отладчик открывал.

Как всегда, руководства Emacs - ваши друзья. См., Например, node Checklist в руководстве Emacs и node Invoking the Debugger в руководстве Elisp.

Существует еще один отладчик, называемый edebug, который также описан в руководствах. Некоторые люди предпочитают его debug. (Я предпочитаю debug.) Оба хороши.

Использование отладчика, как правило, более информативно, если вы загрузили исходные файлы Emacs Lisp, а не их байт-скомпилированные версии. Если вы начнете расследование конкретной проблемы с помощью отладчика, вы можете сначала загрузить файлы *.el (not *.elc).

Ответ 2

Вы можете отлаживать ваш файл .emacs следующим образом: Отладка файла настройки

Запустите Emacs с параметром командной строки '-debug-init. Это позволяет отладчик Emacs Lisp перед оценкой вашего файла .emacs и мест вы в отладчике, если что-то пойдет не так. Верхняя строка в буфером обратной связи будет сообщение об ошибке, а второе или третье строка этого буфера отобразит код Lisp из вашего файла .emacs что вызвало проблему.

Вы также можете оценить отдельную функцию или аргумент функции в файле .emacs, переместив курсор в конец функции или аргумент и ввод C-x C-e (M-x eval-last-sexp).

Используйте C-h v (M-x describe-variable), чтобы проверить значение переменных которые вы пытаетесь установить или использовать.

Ответ 3

У меня был большой успех с охотником за ошибками elisp https://github.com/Malabarba/elisp-bug-hunter.

Наиболее распространенными проблемами являются несогласованные скобки, пакеты с загрузкой.:

Автоматическая ошибка поиска ошибок

Если ваш файл инициализации Emacs сообщает об ошибке во время запуска, но вы не знайте почему, просто выпустите

M-x bug-hunter-init-file RET e

и The Bug Hunter найдет его для вас. Обратите внимание, что ваш init.el(или .emacs) должны быть идемпотентными, чтобы это работало.

Интерактивная охота

Если Emacs запускается без ошибок, но что-то не работает должен вызывать ту же команду, но выберите интерактивную опцию:

M-x bug-hunter-init-file RET i

Охотник за ошибками запускает отдельный экземпляр Emacs несколько раз, и то он будет спрашивать вас каждый раз, представит ли этот экземпляр проблема у вас есть. Сделав это примерно в 5-12 раз, вам дадут результаты.

Ответ 4

Я добавлю это, чтобы предвидеть. Функция ниже, исходящая из oremacs.com позволяет проверить достоверность нашего файла инициализации (или любого другого файла) без запуска emacs:

(defun ora-test-emacs ()
  (interactive)
  (require 'async)
  (async-start
   (lambda () (shell-command-to-string
          "emacs --batch --eval \"
(condition-case e
    (progn
      (load \\\"~/.emacs\\\")
      (message \\\"-OK-\\\"))
  (error
   (message \\\"ERROR!\\\")
   (signal (car e) (cdr e))))\""))
   `(lambda (output)
      (if (string-match "-OK-" output)
          (when ,(called-interactively-p 'any)
            (message "All is well"))
        (switch-to-buffer-other-window "*startup error*")
        (delete-region (point-min) (point-max))
        (insert output)
        (search-backward "ERROR!")))))

Можно даже добавить тест Travis CI.

ps: решения суммируются на wikemacs.

Ответ 5

Некоторые полезные советы уже были даны. В частности, я думаю, что ответ @Drew в значительной степени охватывает то, что вам нужно делать.

Я хотел бы также упомянуть, что то, как вы структурируете свой файл конфигурации, также помогает справиться с проблемами. Например, группировка похожих или связанных параметров конфигурации вместе может быть очень полезной.

Однако одна вещь, которую я считаю наиболее полезной, - это разбить мою конфигурацию на отдельные файлы. По сути, мой файл init.el ничего не делает, кроме как настроить некоторые параметры пути загрузки, чтобы можно было найти мой фактический код конфигурации, а затем просто нужно вызвать "'" для загрузки каждого из файлов.

В моем каталоге .emacs.d у меня есть каталог с именем lisp и в этом каталоге у меня есть куча файлов *.el с именами, такими как init-org.el, init- clojure.el, init-javascript.el и т.д. В каждом из этих файлов у меня есть настройки конфигурации, относящиеся к имени, например, org setup stuff в init-org.el, javascript в init-javascript.el и т.д.

Каждый из этих файлов заканчивается формой "предоставить" i.e.

(provide 'init-org)

в конце init-org.el и

(provide 'init-javascript)

в конце init-javascript.el и т.д.

В моем файле init.el у меня есть строки типа

(add-to-list 'load-path (expand-file-name "lisp" user-emacs-directory))

(require 'init-org)
(require 'init-javascript)
(require 'init-clojre)

Преимущество этого заключается в том, что теперь стало проще деактивировать мой файл init. Я могу просто прокомментировать первую половину требуемых утверждений - гораздо меньше строк.

другое преимущество заключается в том, что иногда, если у меня возникают проблемы с некоторой конфигурацией, но это не связано с работой, которую мне нужно сделать сейчас, я могу просто прокомментировать, что нужно, и вернуться к работе. Например, если я выполняю кодировку clojure, но имею некоторую ошибку при запуске emacs из-за проблемы в моей настройке javascript, тогда я могу просто прокомментировать строку (require-init-javascript), и мне хорошо перейти.