@c -*-texinfo-*-
@c This is part of the GNU Emacs Lisp Reference Manual, Japanese Edition.
@c Copyright (C) 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc. 
@c See the file elisp-jp.texi for copying conditions.
@c 複製の条件はelisp-jp.texiに書いてあります。
@setfilename ../info/debugging-jp
@node Debugging, Read and Print, Byte Compilation, Top
@chapter Lispプログラムのデバッグ

  Emacs Lispのプログラムに問題がおきたとき、
プログラムで何をしていたかによって、
問題を調べるための方法が三つあります。

@itemize @bullet
@item
プログラムの実行中に問題がおきたのなら、
Lispデバッガ
(デフォルトのデバッガかEdebug)
で実行時に何がおきたのか調べられます。

@item
構文にたいする問題点ならば、
Lispはプログラムを読み込むことすらできないはずなので、
EmacsのLisp編集機能を使って局所化できるでしょう。

@item
バイトコンパイラでプログラムをコンパイルしようとしていたのであれば、
コンパイラの入力バッファを調べる方法を知る必要があります。
@end itemize

@menu
* Debugger::            Emacs Lispデバッガの実装方法。
* Syntax Errors::       構文エラーのさがしかた。
* Compilation Errors::  バイトコンパイルしてあらわれたエラーのさがしかた。
* Edebug::		ソース・レベルEmacs Lispデバッガ。
@end menu

  そのほかに便利なデバッグ用ツールとしてドリブル・ファイルがあります。
ドリブル・ファイルを開けると、
キーボードからの入力文字はすべてそのファイルにコピーされます。
後々そのファイルを調べてどんな入力があったか、
確かめることができます。@xref{Terminal Input}。

  端末記述の問題のデバッグには、
@code{open-termscript}関数が便利です。@xref{Terminal Output}。

@node Debugger, Syntax Errors, Debugging, Debugging
@section Lispのデバッガ
@cindex debugger
@cindex Lisp debugger
@cindex break
@cindex デバッガ[でばっが]
@cindex Lispデバッガ[lispでばっが]
@cindex ブレーク[ぶれーく]

  @dfn{Lispデバッガ(Lisp debugger)}は、
形式の評価を途中で止めることができるようにします。
(@dfn{ブレーク(break)}という)評価が止められている状況では、
実行時スタックを調べたり、
ローカルもしくはグローバル変数の値を調べたり、
その値を変更したりできます。
ブレークは再帰編集であるため、
通常のEmacsの編集機能が有効です。
再帰的にデバッガにはいるプログラムを実行することさえ可能です。@xref{Recursive Editing}。

@menu
* Error Debugging::       エラー発生時にデバッガにはいる。
* Infinite Loops::	  抜けないプログラムの停止とデバッグ。
* Function Debugging::    特定の関数の呼出しではいる。
* Explicit Debug::        プログラムの特定の場所ではいる。
* Using Debugger::        デバッガは何をするか、何が見えるか。
* Debugger Commands::     デバッガで使えるコマンド。
* Invoking the Debugger:: 関数@code{debug}の呼び出しかた。
* Internals of Debugger:: デバッガのサブルーチンとグローバル変数。
@end menu

@node Error Debugging, Infinite Loops, Debugger, Debugger
@subsection エラーでデバッガにはいる
@cindex error debugging
@cindex debugging errors
@cindex エラーのデバッグ[えらーのでばっぐ]
@cindex デバッグ、エラーの[でばっぐ、えらーの]

  デバッガにはいる一番重要な場合はLispエラーのおきたときです。
これでエラーによる直接的な結果を調べることができます。

  普段はエラーの結果としてデバッガにはいることはありません。
多くのコマンドは、
不適切なところで実行されると
(バッファの最後での@kbd{C-f})
よくLispエラーになるので、
通常の編集の最中にデバッガを呼び出すのは非常に困ります。
エラーのたびにデバッガにはいらせるには、
@code{debug-on-error}を非@code{nil}にします。

@defopt debug-on-error
この変数は、ハンドルされないエラーが通知された場合、デバッガを呼
ぶべきか否かを定めます。
もし@code{debug-on-error}が@code{t}なら、
すべてのエラーでデバッガを呼びます。
@code{nil}の場合、デバッガは呼びません。

値はデバッガを呼ぶエラー・コンディションのリストでもかまいません。
たとえば、これをリスト@code{(void-variable)}に設定すると、
値のない変数についてのエラーだけがデバッガを呼びます。

この変数が非@code{nil}のとき、
プロセス・フィルターと見張りの処理で発生したエラーをEmacsが捕捉することはありません。
したがって、
このようなエラーでもデバッガを起動します。@xref{Processes}。
@end defopt

  @file{.emacs}ファイルのロード中におきるエラーをデバッグするには、
@c Overfull対策
@iftex
オプション@samp{-debug-@linebreak{}init}を使います。
@end iftex
@ifinfo
オプション@samp{-debug-init}を使います。
@end ifinfo
これは@file{.emacs}をロードしている間@code{debug-on-error}を@code{t}に束縛し、
@code{condition-case}で初期化ファイルのエラーをとらまえるのを禁止します。

  もし@file{.emacs}ファイルで@code{debug-on-error}を設定しても、
その効果は@file{.emacs}のロードが終わるまでしかありません
(これは@samp{-debug-init}コマンド行オプションを実装する際に生じた
望ましくない副産物です)。
@file{.emacs}ファイルに@code{debug-on-error}を永久的に設定させるには、
次のように@code{after-init-hook}を使います。

@example
(add-hook 'after-init-hook
          '(lambda () (setq debug-on-error t)))
@end example

@node Infinite Loops, Function Debugging, Error Debugging, Debugger
@subsection 無限ループのデバッグ
@cindex infinite loops
@cindex loops, infinite
@cindex quitting from infinite loop
@cindex stopping an infinite loop
@cindex 無限ループ[むげんるーぷ]
@cindex ループ、無限[るーぷ、むげん]
@cindex とりやめ、無限ループの[とりやめ、むげんるーぷの]
@cindex 一時停止、無限ループの[いちじていし、むげんるーぷの]

  プログラムが無限にループして、
戻れなくなっているとき、
最初の問題はループを止めることです。
ほとんどのオペレーティング・システムでは、
とりやめをする@kbd{C-g}でこれができます。

  とりやめでは通常、
なぜプログラムがループしたのかについての情報を教えてはくれません。
より詳しい情報を得るには、
変数@code{debug-on-quit}を非@code{nil}に設定します。
@kbd{C-g}によるとりやめはエラーとはみなしません。
@code{debug-on-error}は@kbd{C-g}のハンドリングについての効果がありません。
同様に@code{debug-on-quit}はエラーについての効果がありません。

  無限ループの途中でデバッガを動かすと、
ステップ・コマンドを使ってデバッガからの続行が可能です。
ループ全体をステップすれば、
おそらく問題を解くのに十分な情報が得らえるでしょう。

@defopt debug-on-quit
この変数は、@code{quit}が通知されハンドルされなかった場合、
デバッガを呼ぶべきか否かを定めます。
@code{debug-on-quit}が非@code{nil}の場合、
とりやめる
(つまり@kbd{C-g}を押下する)
ごとにデバッガを呼びます。
@code{debug-on-quit}が@code{nil}の場合、
とりやめてもデバッガは呼ばれません。@xref{Quitting}。
@end defopt

@node Function Debugging, Explicit Debug, Infinite Loops, Debugger
@subsection 関数呼出しでデバッガにはいる
@cindex function call debugging
@cindex debugging specific functions
@cindex 関数呼出しのデバッグ[かんすうよびだしのでばっぐ]
@cindex 一定の関数のデバッグ[いっていのかんすうのでばっぐ]
@cindex デバッグ、指定した関数の[でばっぐ、していしたかんすうの]

  プログラムの途中でおきる問題を調べるときに便利な手法として、
特定の関数を呼び出したときには必ずデバッガにはいる、
というのがあります。
問題のおきる関数や問題のおきるところより前の関数をこう設定しておいて、
その関数を呼ぶまでは素速くステップしたり、
呼出し元に戻るまでステップしたりできます。

@deffn Command debug-on-entry function-name
  この関数は、
@var{function-name}が呼ばれるたびにデバッガを起動するようにします。
これは形式@code{(debug 'debug)}を関数定義の最初の形式として挿入すること
で行ないます。

  Lispコードで定義された関数は、
解釈されるコードであれコンパイルされたコードであれ、
どれでも(訳注:関数に)はいるときのブレークを設定できます。
関数がコマンドなら、
Lispから呼ばれた場合も、
対話的に呼ばれた場合も
(引数を読み込んだ後)
デバッガにはいります。
プリミティブ関数
(すなわちCで書かれた関数)
はこの方法でのデバッグはできません。

  @code{debug-on-entry}が対話的に呼ばれた場合、
@var{function-name}を求めミニバッファにプロ
ンプトを出します。

  すでに関数へはいるときにデバッガを起動するよう設定してある場合、
@code{debug-on-entry}は何も行ないません。

  @strong{注意!:}
@code{debug-on-entry}の後で関数を再定義すると、
デバッガにはいるコードはなくなります。

  @code{debug-on-entry}は@var{function-name}を返します。

@example
@group
(defun fact (n)
  (if (zerop n) 1
      (* n (fact (1- n)))))
     @result{} fact
@end group
@group
(debug-on-entry 'fact)
     @result{} fact
@end group
@group
(fact 3)
@end group

@group
------ Buffer: *Backtrace* ------
Entering:
* fact(3)
  eval-region(4870 4878 t)
  byte-code("...")
  eval-last-sexp(nil)
  (let ...)
  eval-insert-last-sexp(nil)
* call-interactively(eval-insert-last-sexp)
------ Buffer: *Backtrace* ------
@end group

@group
(symbol-function 'fact)
     @result{} (lambda (n)
          (debug (quote debug))
          (if (zerop n) 1 (* n (fact (1- n)))))
@end group
@end example
@end deffn

@deffn Command cancel-debug-on-entry function-name
この関数は、@var{function-name}にたいする@code{debug-on-entry}を取り消します。
対話的に呼ばれた場合、@var{function-name}を求めミニバッファにプロ
ンプトを出します。
もし@var{function-name}が@code{nil}や空文字列の場合は、
全関数のデバッグを取り消します。

@findex debug-on-entry
同じ関数にたいし@code{debug-on-entry}を複数回呼んだ場
合、2回目の呼出しは何も行ないません。
@code{cancel-debug-on-entry}は@var{function-name}を返します。
@end deffn

@node Explicit Debug, Using Debugger, Function Debugging, Debugger
@subsection 陽にデバッガへはいる

  プログラムに式@code{(debug)}を書いてデバッガを呼ぶこともできます。
そうするにはソース・ファイルを読み込み、
テキスト@samp{(debug)}を挿入し@kbd{C-M-x}を押下します。
セーブする前に挿入を取り消すのを忘れないでください!

  @samp{(debug)}を入れるのは、
付加的な形式が評価されかつその値が無視されるような場所でなければなりません。
(@code{(debug)}の値が無視されなければ、
プログラムの実行を変えることになります!)
適切で、
ありがちな場所は@code{progn}や暗黙@code{progn}の内側です(@pxref{Sequencing})。

@node Using Debugger, Debugger Commands, Explicit Debug, Debugger
@subsection デバッガを使う

  デバッガにはいると、
@c Overfull対策
@c ちょっと日本語が変かな?
@c 以前に選択していたバッファを片方のウィンドウに、
以前に選択していたバッファを片方のウィンドウに表示し、
そして@samp{*Backtrace*}という名前のバッファを別のウィンドウに表示します。
バックトレース・バッファには、
1行ごとに現在のLisp関数実行の各レベルが示されます。
このバッファの最初に、
デバッガが呼び出された理由を示したメッセージがあります
(たとえば、エラーによって呼び出された場合は、
エラー・メッセージとそれに関連するデータです)。

  バックトレース・バッファは読出し専用で、
Debuggerモードという特別の主モードになっています。
そこでは、文字がデバッガ・コマンドとして定義されています。
普通のEmacs編集コマンドも使えます。
エラーの際に編集していたバッファを調べるためにウィンドウを切替えたり、
バッファを切替えたり、
ファイルを読み込んだりなどの編集もできます。
しかし、デバッガは再帰編集レベルにあります(@pxref{Recursive Editing})。
デバッガを使う必要がなくなったときは、
バックトレース・バッファに戻って
(@kbd{q}コマンドで)
正式にデバッガを抜けなければなりません。
デバッガから抜けると、
再帰編集を終わらせてバックトレース・バッファをkillします。

@cindex current stack frame
@cindex 現在のスタック・フレーム[げんざいのすたっくふれーむ]
  バックトレース・バッファには、
実行している関数とそれに与えられた引数の値が表示されます。
また、ポイントを動かして、
その行が示しているスタック・フレームを指定する目的にも使えます
(スタック・フレームとは、
Lispインタプリタが関数の実行についての情報を記録しておく場所です)。
ポイントがある行のフレームを@dfn{現在のフレーム(current frame)}とみなします。
デバッガ・コマンドのいくつかは現在のフレームに作用します。

  デバッガ自身にスタック・フレームをいくつ作るかという仮定をするため、
デバッガ自身はバイトコンパイルした上で動作させる必要があります。
解釈されて動作しているときにはこの仮定がくずれてしまいます。

@need 3000

@node Debugger Commands, Invoking the Debugger, Using Debugger, Debugger
@subsection デバッガ・コマンド
@cindex debugger command list
@cindex デバッガ・コマンド一覧[でばっがこまんどいちらん]

  デバッガ(Debuggerモード)の中では、
通常のカーソル移動コマンドのほかに特殊なコマンドが有効です
(Emacsの普通の機能、
たとえば、ウィンドウやバッファを切替えたりすることは、
ずっと有効なことを忘れないでください)。

  デバッガ・コマンドはコードにそってステップ実行するのに主に使われます。
これでどのように制御が流れるのかを見ることができます。
デバッガは解釈された関数の制御構造にそってステップできますが、
バイトコンパイルされた関数ではできません。
バイトコンパイルされた関数でそうしたいなら、
同じ関数を解釈されるような再定義に置き換えてください
(それには関数のソース・ファイルを読み込み、
その定義のあるところで@kbd{C-M-x}を押下します)。

  以下はDebuggerモードのコマンドの一覧です。

@table @kbd
@item c
デバッガを抜けて実行を再開します。
再開が可能ならば、
あたかもデバッガにはいらなかったかのように
(デバッガ内で変更した変数やデータ構造の作用は別として)
プログラムの実行を続けます。

再開が可能なのは、
関数の入口、出口、陽に(訳注: デバッガを)呼び出したとき、
@kbd{C-g}によるとりやめ、
などがあります。
エラーのせいでデバッガにはいったときは続行ができません。

@item d
実行を再開しますが、
次にLisp関数が呼び出されるとまたデバッガにはいります。
これによって、一つの式の中の各式をステップ実行することができ、
それらの式が計算する値など実行状況を見ることができます。

このようにしてデバッガにはいった関数呼出しのスタック・フレームには、
そのフレームから抜けるときにもデバッガにはいるように自動的に印がつけられます。
この印を消すには@kbd{u}コマンドを使います。

@item b
現在のフレームから抜けるときにデバッガにはいるようフレームに印をつけます。
このように印をつけたフレームには、
バックトレース・バッファで星を表示します。

@item u
現在のフレームから抜けるときにはデバッガにはいらないようにします。
これはフレームでの@kbd{b}コマンドの取り消しになります

@item e
Lisp式をミニバッファから読み込んで評価し、
その値をエコー領域に表示します。
デバッガは実行中にある重要な変数群を変更し、
操作の一部分としてカレント・バッファも変更します。
@kbd{e}は一時的にデバッガの外での値に復帰するので、
その変数の値も調べることができます。
これでデバッガがかなり透過的になります。
一方@kbd{M-:}は、デバッガの中でも特殊なことをしません。
デバッガの中での変数の値を表示します。

@item q
デバッグしているプログラムを終了します。
Emacsのコマンド実行のトップレベルに戻ります。

@kbd{C-g}によってデバッガにはいったが、
デバッグではなく本当にとりやめをしたいときに、
@kbd{q}コマンドを使います。

@item r
デバッガから値を返します。
その値はミニバッファで式を読み込み、評価して求めます。

@kbd{r}コマンドは
(@kbd{b}を指定して)
Lispの呼出しフレームから抜けたために呼び出されたデバッガでは便利です。
また、@code{debug}を呼んだときの値を使用するというときにも便利です。
それ以外の場合では、
@kbd{r}と@kbd{c}は同じで、
指定した値は無視されます。

エラーのせいでデバッガにはいったとき@kbd{r}は使えません。
@end table

@node Invoking the Debugger, Internals of Debugger, Debugger Commands, Debugger
@subsection デバッガの起動

  ここではデバッガを起動するための関数について詳しく述べます。

@defun debug &rest debugger-args
この関数は、デバッガにはいります。
バッファを@samp{*Backtrace*}
(2番目の再帰編集の場合@samp{*Backtrace*<2>}など)
という名前のバッファに切替え、
Lisp関数呼出しのスタックに関する情報を出力します。
この後、
バックトレース・バッファをDebuggerモードにして、
再帰編集にはいります。

Debuggerモードの@kbd{c}と@kbd{r}コマンドは再帰編集を抜けます。
@code{debug}は前のバッファに戻し、
@code{debug}の呼び出したところに返します。
これは関数@code{debug}が呼出し元に返る唯一の方法です。

@code{debug}に渡した@var{debugger-args}の先頭が@code{nil}の場合
(またはそれが後述する表にある特殊な値でない場合)、
残りの引数は@samp{*Backtrace*}バッファの先頭に表示されます。
このしくみはユーザへのメッセージを表示するのに使います。

しかし、@code{debug}の最初の引数が以下の特殊な値の一つである場合、
特別な意味をもちます。
通常、デバッガとEmacsの内部だけがそれらの値を@code{debug}に渡し、
@code{debug}を呼んでいるプログラマが用いることはありません。

特別な値は、

@table @code
@item lambda
@cindex @code{lambda} in debug
@cindex @code{lambda}、デバッグ中の[lambda、でばっぐちゅうの]
最初の引数が@code{lambda}の場合は、
@code{debug-on-next-call}が@code{nil}でなかったときに関数を呼んだため、
@code{debug}にはいったということを意味します。
デバッガはバッファの先頭行に@samp{Entering:}を表示します。

@item debug
最初の引数が@code{debug}のときは、
関数にはいったときにデバッグするよう設定した関数に、
はいったことを示します。
@code{lambda}の場合と同様に、
デバッガは@samp{Entering:}を表示します。
この関数のスタック・フレームに印をつけて、
この関数から抜けたときにデバッガを起動するようにします。

@item t
最初の引数が@code{t}の場合は、
@code{debug-on-next-call}が非@code{nil}のときにリスト形式を評価したために、
@code{debug}を呼んだことを意味します。
デバッガはバッファの先頭行に

@smallexample
Beginning evaluation of function call form:
@end smallexample

@noindent
を表示します。

@item exit
最初の引数が@code{exit}の場合は、
フレームから抜けるときにデバッガを呼ぶように
あらかじめ印をつけておいたスタック・フレームが、
抜けたことを示すのに用います。
この場合の@code{debug}の次の引数は、
フレームの返した値です。
バッファの先頭行に@samp{Return value:}を表示し、
返された値をこれに続けて表
示します。

@item error
@cindex @code{error} in debug
@cindex @code{error}、デバッグ中の[error、でばっぐちゅうの]
第1引数が@code{error}の場合、
エラーか@code{quit}が通知されハンドルされなかったため、
デバッガにはいったことを示すのに用います。
@samp{Signalling:}を表示し、
通知されたエラーと@code{signal}にたいする引数とを後につけて表示します。
たとえば、

@example
@group
(let ((debug-on-error t))
  (/ 1 0))
@end group

@group
------ Buffer: *Backtrace* ------
Signaling: (arith-error)
  /(1 0)
...
------ Buffer: *Backtrace* ------
@end group
@end example

エラーが通知されたのなら、
当然変数@code{debug-on-error}は非@code{nil}です。
@code{quit}が通知されたのなら、
当然変数@code{debug-on-quit}は非@code{nil}です。

@item nil
あなたが陽にデバッガにはいりたいときは、
@var{debugger-args}の最初に@code{nil}を使います。
バッファの先頭行に@var{debugger-args}の残りを表示します。
たとえば、@code{debug}を呼んだ条件を思い出すためメッセージを表示するのに、
この機能を使うことができます。
@end table
@end defun

@node Internals of Debugger,  , Invoking the Debugger, Debugger
@subsection デバッガの内部

  この節ではデバッガ内部で使っている関数と変数について述べます。

@defvar debugger
この変数の値は、デバッガを起動するために呼ぶ関数です。
この値は、
任意個の引数
をもちうる関数(もしくは、より一般的には関数の名前)でなくてはい
けません。
この関数は、
何らかのデバッガにはいるものとされます。
この変数のデフォルト値は@code{debug}です。

Lispがこの関数に渡す最初の引数は、
どのように呼ばれたかを示します。
引数に関する慣例の詳細は、
@code{debug}の記述で述べられています。
@end defvar

@deffn Command backtrace
@cindex run time stack
@cindex call stack
@cindex 実行時のスタック[じっこうじのすたっく]
@cindex 呼出しスタック[よびだしすたっく]
この関数は、今現在アクティブになっているLisp関数呼出しのトレースを印字します。
これは@code{debug}で@samp{*Backtrace*}バッファを作る際、用いる関
数です。
どの関数呼出しがアクティブなっているかを調べるのにスタックをアクセ
スしなくてはいけないため、この関数は、Cで書かれています。
常に@code{nil}を返します。

次はLisp式で陽に@code{backtrace}を呼んだ例です。
これはバックトレースをストリーム@code{standard-output}に印字します。
この場合は@samp{backtrace-output}です。
バックトレースの各行が関数の一つの呼出しを表わします。
関数の引数の値がわかっているときは、各行に表示します。
計算中の場合はそのように表わします。
(この例では)特殊形式の引数が省略されています。

@smallexample
@group
(with-output-to-temp-buffer "backtrace-output"
  (let ((var 1))
    (save-excursion
      (setq var (eval '(progn
                         (1+ var)
                         (list 'testing (backtrace))))))))

     @result{} nil
@end group

@group
----------- Buffer: backtrace-output ------------
  backtrace()
  (list ...computing arguments...)
  (progn ...)
  eval((progn (1+ var) (list (quote testing) (backtrace))))
  (setq ...)
  (save-excursion ...)
  (let ...)
  (with-output-to-temp-buffer ...)
  eval-region(1973 2142 #<buffer *scratch*>)
  byte-code("...  for eval-print-last-sexp ...")
  eval-print-last-sexp(nil)
* call-interactively(eval-print-last-sexp)
----------- Buffer: backtrace-output ------------
@end group
@end smallexample

文字@samp{*}は、
フレームのdebug-on-exitフラグが設定されていることを表わします。
@end deffn

@ignore @c Not worth mentioning
@defopt stack-trace-on-error
@cindex stack trace
This variable controls whether Lisp automatically displays a
backtrace buffer after every error that is not handled.  A quit signal
counts as an error for this variable.  If it is non-@code{nil} then a
backtrace is shown in a pop-up buffer named @samp{*Backtrace*} on every
error.  If it is @code{nil}, then a backtrace is not shown.

When a backtrace is shown, that buffer is not selected.  If either
@code{debug-on-quit} or @code{debug-on-error} is also non-@code{nil}, then
a backtrace is shown in one buffer, and the debugger is popped up in
another buffer with its own backtrace.

We consider this feature to be obsolete and superseded by the debugger
itself.
@end defopt
@end ignore

@defvar debug-on-next-call
@cindex @code{eval}, and debugging
@cindex @code{apply}, and debugging
@cindex @code{funcall}, and debugging
@cindex @code{eval}とデバッグ[evalとでばっぐ]
@cindex @code{apply}とデバッグ[applyとでばっぐ]
@cindex @code{funcall}とデバッグ[funcallとでばっぐ]
この変数が非@code{nil}のとき、
次の@code{eval}、@code{apply}、
@code{funcall}の前にデバッガを呼ぶべきであることを示します。
デバッガが@code{nil}にします。

デバッガの@kbd{d}コマンドの動きはこの変数の設定によります。
@end defvar

@defun backtrace-debug level flag
この関数は、
@var{level}レベル下のスタック・フレームのdebug-on-exitフラグを@var{flag}に設定します。
@var{flag}が非@code{nil}の場合、
そのフレームを抜ける際、
デバッガにはいるようにします。
フレームから局所的でない抜けかたをしてもデバッガにはいりま
す。

この関数は、デバッガからのみ呼ばれます。
@end defun

@defvar command-debug-status
この変数は、現在の対話的なコマンドのデバッグ状態を記録します。
コマンドが対話的に呼ばれるたびにこの変数は、@code{nil}に束縛されます。
デバッガは同じコマンドの実行中にあとで別なデバッガを起動するときのために
情報を残しておくのにこの変数を設定しておくことがあります。

別のグローバル変数でなくこの変数を使うことの、
デバッガにとっての利点は、
ひき続くコマンドの呼出しにデータを渡さないようにすることです。
@end defvar

@defun backtrace-frame frame-number
関数@code{backtrace-frame}はLispデバッガが使うことを想定しています。
@var{frame-number}レベル下のスタック・フレームでおきている計算についての情報を返します。

そのフレームがまだ引数を評価していない(あるいは、特殊形式である)場合は、
値は@code{(nil @var{function} @var{arg-forms}@dots{})}です。

そのフレームが引数を評価し、すでに関数を呼んでしまっているときは、
値は@code{(t @var{function} @var{arg-values}@dots{})}です。

戻り値における@var{function}は、
計算中のリストの@sc{car}として与えられているもの、
あるいはマクロ呼出しの場合は@code{lambda}式となります。
関数に@code{&rest}引数があるときは、
リスト@var{arg-values}の最後になります。

@var{frame-number}が範囲外のとき、
@code{backtrace-frame}は@code{nil}を返します。
@end defun

@node Syntax Errors, Compilation Errors, Debugger, Debugging
@section 誤ったLisp構文のデバッグ

  Lispリーダは不正な構文について知らせてくれますが、
どこに真の問題があるのかについては、
何も教えてはくれません。
たとえば、エラー``End of file during parsing''
(訳注:構文解析中にファイル終了)
が式の評価中におこったら、
開き括弧(あるいは角括弧)が多すぎることを示します。
リーダはファイルの最後で不釣合いを検出しますが、
閉じ括弧をどこに置くべきかはわかりません。
同様に``Invalid read syntax: ")"''は、
閉じ括弧が多すぎるのか開き括弧が少なすぎることを示しますが、
対応する括弧がどこなのかはわかりません。
このときにどうやって変えるところを見つけるのでしょうか?

  問題が単に括弧の不釣合いでないとしても、
各defunの先頭で@kbd{C-M-e}をやってみて、
defunの最後にゆくかどうかを見るのは、
便利な手法です。
もし最後に行かないのなら、
問題はそのdefunにあります。

@c  XXX すいません、unmatchは不対応とし、balanceを釣り合うとしましょう。
  しかしながら、括弧の不対応はLispでは一番ありがちな構文エラーなので、
これに対処するための助言はさらに続きます。

@menu
* Excess Open::     余計な開き括弧や足りない閉じ括弧の見つけ方。
* Excess Close::    余計な閉じ括弧や足りない開き括弧の見つけ方。
@end menu

@node Excess Open, Excess Close, Syntax Errors, Syntax Errors
@subsection 余計な開き括弧

  最初のステップは不釣合いなdefunを見つけることです。
開き括弧が多いときは、
ファイルの最後に閉じ括弧を置いて@kbd{C-M-b} (@code{backward-sexp})を実行します。
こうすると不釣合いなdefunの先頭に来ることになります
(そして@kbd{C-@key{SPC} C-_ C-u C-@key{SPC}}で、
マークを設定し閉じ括弧の挿入を取り消し、
マークの場所に戻ることができます)。

  次のステップはどこが誤っているのか決定することです。
プログラムから学ぶこと以外には、
これについて確かなことをいうことはできませんが、
往々にして、
既存の字下げが、
括弧がどこにあるべきかについての手がかりになることがあります。
この手がかりを使う一番簡単な方法は、
@kbd{C-M-q}で字下げしてどこが動くかを見ることです。

  これをやる前には、
defunに十分な数の閉じ括弧があることを確認しておいてください。
さもないと、
@kbd{C-M-q}はエラーになるか、
ファイルの最後までを全部字下げしてしまうことになります。
ですから、
defunの最後に行って閉じ括弧をいれます。
defunが釣合っていなければだめなので、
ここで@kbd{C-M-e}を使ってはいけません。

  さてここでdefunの先頭に行き@kbd{C-M-q}を押下します。
普通はある点以下のすべての行が右にずれるはずです。
多分その点の近くになくなった閉じ括弧か余計な開き括弧があるはずです
(しかしながら常にそうとはかぎりません。
コードから学んで確かめてください)。
くいちがいがみつかったら@kbd{C-M-q}を@kbd{C-_}で取り消します。
なぜなら前の字下げの方が、
意図していた括弧にたいしておそらく適切なはずだからです。

  問題が直ったと考えたら、
ふたたび@kbd{C-M-q}を使います。
前の字下げが意図した括弧のネストと実際に合っていて、
その括弧を戻したのであれば、
@kbd{C-M-q}では何も変わらないはずです。

@node Excess Close,  , Excess Open, Syntax Errors
@subsection 余計な閉じ括弧

  余計な閉じ括弧を扱うには、
まずファイルの先頭に開き括弧を置いて1文字戻り、
@kbd{C-M-f}を押下し、
不釣合いなdefunの最後に行きます
(そして@kbd{C-@key{SPC} C-_ C-u C-@key{SPC}}で、
マークを設定し開き括弧の挿入を取り消し、
マークの場所に戻ることができます)。

    そして実際に対応する閉じ括弧を見つけるには、
defunの先頭で@kbd{C-M-f}を押下します。
defunが終るべき場所より手前に来ることがあるかもしれませんが、
おそらくそのへんで余計な閉じ括弧を見つけることができるでしょう。

  そこで問題がみえてこなければ、
次にすべきことはdefunの先頭で@kbd{C-M-q}を押下することです。
何行かは左にずれるはずです。
そのときに、
なくなった開き括弧や余計な閉じ括弧が、
ずれた行の前の方にあるはずです
(しかしながら常にそうとはかぎりません。
コードから学んで確かめてください)。
くいちがいがみつかったら@kbd{C-M-q}を@kbd{C-_}で取り消します。
なぜなら前の字下げの方が、
意図していた括弧にたいしておそらく適切なはずだからです。

  問題が直ったと考えたら、
ふたたび@kbd{C-M-q}を使います。
前の字下げが意図した括弧のネストと実際に合っていて、
その括弧を戻したのであれば、
@kbd{C-M-q}では何も変わらないはずです。

@node Compilation Errors, Edebug, Syntax Errors, Debugging
@section コンパイル時の問題のデバッグ

  バイトコンパイル中にエラーがおきたときは、
通常はコンパイルしているプログラム中の構文エラーが原因です。
コンパイラは適切なエラー・メッセージを@samp{*Compile-Log*}バッファに印字して、
止まります。
メッセージの中にはエラーがみつかった関数名があることもありますが、
ないこともあります。
いずれにせよ、
以下ではファイルのどこでエラーがおきたのかを見つける方法について述べます。

  まずすべきことはバッファ@w{@samp{ *Compiler Input*}}に切替えることです。
(バッファ名がスペースで始まっているため、
@kbd{M-x list-buffers}では表示されません。)
このバッファにはコンパイル中のプログラムがあり、
ポイントはバイトコンパイラがどこまで読み込んだかを示します。@refill

  エラーが不正なLisp構文によるものならば、
ポイントは不正な構文を@emph{検出}したまさにその場所を示します。
エラーの原因はその近くとはかぎりません。
前節の手法を使ってエラーを見つけてください。

  もしエラーが、
首尾よく読み込めた形式のコンパイル中に検出されたのなら、
ポイントはその形式の後にあるはずです。
この場合、
今の手法ではエラーを正確に局所化することはできませんが、
どの関数を調べればいいのかはわかります。

@include edebug-jp.texi
