デバッガに入るタイミングとして一番重要なのは、Lispエラーが発生したときです。デバッガではエラーの直接原因を調査できます。
しかしデバッガへのエンターは、エラーによる通常の結末ではありません。多くのコマンドは不適切に呼び出されたときにLispエラーをシグナルするので、通常の編集の間にこれが発生するたびデバッガにエンターするのは、とても不便でしょう。したがってエラーの際にデバッガにエンターしたいなら、変数debug-on-error
に非nil
をセットします(コマンドtoggle-debug-on-error
はこれを簡単に行う方法を提供する)。
再表示コードによって呼び出されたLispエラーは、技術的な理由によりこのサブセクションで定義されている機能ではデバッグできないことに注意してください。これらについてのヘルプについては再表示エラーのデバッグを参照してください。
この変数はエラーがシグナルされて、それがハンドルされていないときにデバッガを呼び出すかどうかを決定する。debug-on-error
がt
なら、debug-ignored-errors
(以下参照)にリストされているエラー以外の、すべての種類のエラーがデバッガを呼び出す。nil
ならデバッガを呼び出さない。
値にはエラー条件(エラーをシグナルする方法を参照)のリストも指定できる。その場合はこのリスト内のエラー条件だけによってデバッガが呼び出される(debug-ignored-errors
にもリストされているエラー条件は除外される)。たとえばdebug-on-error
をリスト(void-variable)
にセットすると、値をもたない変数に関するエラーにたいしてのみデバッガが呼び出される。
eval-expression-debug-on-error
がこの変数をオーバーライドするケースがいくつかあることに注意(以下参照)。
この変数が非nil
のとき、Emacsはプロセスフィルター関数と番兵(sentinel)の周囲にエラーハンドラーを作成しない。したがってこれらの関数内でのエラーは、デバッガを呼び出す。プロセスを参照のこと。
この変数はdebug-on-error
の値に関わらず、デバッガにエンターすべきでないエラーを指定する。変数の値はエラー条件のシンボルおよび/または正規表現のリスト。エラーがこれら条件シンボルのいずれか、またはエラーメッセージが正規表現のいずれかにマッチすれば、そのエラーはデバッガにエンターしない。
この変数の通常の値にはuser-error
、および編集中に頻繁に発生するがLispプログラムのバグに起因することは稀であるような、いくつかのエラーが含まれる。しかし“稀である”ことは“絶対ない”ということではない。あなたのプログラムがこのリストにマッチするエラーによって機能しないなら、そのエラーをデバッグするためにこのリストの変更を試みるのもよいだろう。通常はdebug-ignored-errors
をnil
にセットしておくのが、もっとも簡単な方法である。
この変数が非nil
値(デフォルト)なら、コマンドeval-expression
の実行により一時的にdebug-on-error
がt
がバインドされる。Evaluating Emacs Lisp Expressions in The GNU Emacs
Manualを参照のこと。
eval-expression-debug-on-error
がnil
なら、eval-expression
の間もdebug-on-error
の値は変更されない。
condition-case
でキャッチされたエラー、は通常は決してデバッガを呼び出さない。condition-case
はデバッガがそのエラーをハンドルする前にエラーをハンドルする機会を得る。
debug-on-signal
を非nil
値に変更すると、condition-case
の存在如何に関わらずすべてのエラーにおいてデバッガが最初に機会を得る(デバッガを呼び出すためには依然としてそのエラーがdebug-on-error
とdebug-ignored-errors
で指定された条件を満たさなければならない)。
たとえばemacsclientの--evalオプションによるコードの評価からバックトレースを取得するためにはこの変数をセットすると便利。この変数が非nil
のときにemacsclientで評価されたLispコードがエラーをシグナルすると、バックトレースは実行中のEmacsにポップアップされる。
警告:
この変数を非nil
にセットすると、芳しくない効果があるかもしれない。Emacsのさまざまな部分で処理の通常の過程としてエラーがキャッチされており、そのエラーが発生したことに気づかないことさえあるかもしれない。condition-case
でラップされたコードをデバッグする必要があるなら、condition-case-unless-debug
(see エラーを処理するコードの記述を参照)の使用を考慮されたい。
debug-on-event
をスペシャルイベント(スペシャルイベントを参照)にセットすると、Emacsはspecial-event-map
をバイパスしてこのイベントを受け取ると即座にデバッガへのエンターを試みる。現在のところサポートされる値は、シグナルSIGUSR1
とSIGUSR2
に対応する値のみ(これがデフォルト)。これはinhibit-quit
がセットされていて、それ以外はEmacsが応答しない場合に有用かもしれない。
debug-on-message
に正規表現をセットした場合は、それにマッチするメッセージがエコーエリアに表示されると、Emacsはデバッガにエンターする。たとえばこれは特定のメッセージの原因を探すのに有用かもしれない。
‘*Backtrace*’バッファーのカレントスタックフレーム内のフォームはeコマンドで評価できる。またedebug中ならeやC-x
C-eのコマンドを使用すれば、同様のことを行うことができる。デフォルトではこれらのコマンドによってデバッガは抑制される(この時点でデバッガに(再)エンターすると、デバッグ中のコンテキストから抜け出してしまうので)。しかしdebug-allow-recursive-debug
を非nil
値にセットすると、これらのコマンドが再帰的にデバッガにエンターできるようになる。
initファイルロード中に発生したエラーをデバッグするには、オプション‘--debug-init’を使用する。これはinitファイルロードの間にdebug-on-error
をt
にバインドして、通常はinitファイル内のエラーをキャッチするcondition-case
をバイパスする。