21. プログラムのコンパイルとテスト

前章ではプログラムの変更に便利なEmacsコマンドを説明しました。 本章ではプログラムの大規模な開発や保守を助けるコマンドを説明します。

21.1 Emacs下でのコンパイラの実行

EmacsはCやFortranのような非対話的な言語のコンパイラを 下位プロセスとして実行でき、 そのエラーログをEmacsバッファに取り込めます。 また、エラーメッセージを解析して、 コンパイルエラーを起こしたソース行を提示することもできます。

M-x compile

Emacs下でコンパイラを非同期に実行し、 エラーメッセージを`*compilation*'バッファに取り込む。

M-x grep

Emacs下でgrepを非同期に実行し、 一致した行を`*grep*'バッファに取り込む。

M-x grep-find

指定した引数でfindとgrepを実行し、 出力を`*grep*'バッファに取り込む。

M-x kill-compilation

M-x kill-grep

実行中のコンパイラやgrepのサブプロセスを停止させる。

makeや他のコンパイルコマンドを実行するには、 M-x compileと打ちます。 このコマンドは、ミニバッファでシェルコマンドを読み取り、 そのコマンドを下位シェルで実行し、 出力結果を`*compilation*'という名のバッファに取り込みます。 カレントバッファのデフォルトディレクトリを シェルコマンド実行時の作業ディレクトリとして用います。 そのため、通常はこのディレクトリにあるものをコンパイルします。

シェルコマンド行を読み取るとき、 ミニバッファにはデフォルトのシェルコマンド行が表示されますが、 これは前回M-x compileを使ったときのコマンドです。 単にRETだけを打鍵すると、同じシェルコマンド行を再使用します。 最初のM-x compileでは、デフォルトは`make -k'です。 デフォルトのコンパイルコマンドは変数compile-commandから取ります。 適切なコンパイルコマンドが他にある場合には、 ファイルでこの変数のローカルな値を指定すると便利でしょう （see 節 28.2.5 ファイルにローカルな変数）。

コンパイルが始まると、バッファ`*compilation*'は別のウィンドウに 表示されますが、選択されるわけではありません。 このバッファのモード行では、 括弧の中に単語`run'か`exit'を表示して コンパイルが終了したかどうか示します。 このバッファを見えるようにしておく必要はありません。 いずれにしても、コンパイルは継続されます。 コンパイル中は、すべてのウィンドウのモード行に 文字列`Compiling'が表示されます。 この文字列が消えれば、コンパイルは終了しています。

コンパイルの進行状況を見たい場合には、 `*compilation*'バッファに切り替えてポイントをバッファの末尾に移動します。 ポイントがバッファの末尾にあると、 新らたなコンパイル出力はポイントのまえに挿入されポイントは末尾に留まります。 ポイントがバッファの末尾にないと、 コンパイル出力はバッファの末尾に追加されますが ポイントは途中の場所に留まったままです。

変数compilation-scroll-outputにnil以外の値を設定すると、 出力が到着するたびに出力に追従するように コンパイルバッファをつねにスクロールします。

コンパイルプロセスを止めるには、 M-x kill-compilationを実行します。 コンパイルプロセスが終了すると、`*compilation*'バッファの モード行の表示が`run'から`signal'に変わります。 一度に実行可能なコンパイルは1つだけなので、 新しくコンパイルを始めると実行中のコンパイルは停止させられます。 しかし、M-x compileは、 実行中のコンパイルを実際に停止させるかどうか聞いてきます。

21.2 Emacs下でのgrepによる探索

Emacsからコンパイラを実行し、コンパイルエラーを起こした行を 訪れることができるように、grepを実行して 一致した行を訪れることができます。 これは、grepが報告した一致を『エラー』として扱うことで行います。

それには、M-x grepと打鍵してから、 grepをどのように実行するかを指定するコマンド行を入力します。 普通にgrepを実行するときに指定する引数と同じものを使います。 つまり、grep流の （普通、シェルの特殊文字をクォートするためにシングルクォートで囲んだ） 正規表現に続けて、ワイルドカードなどを用いたファイル名を指定します。 grepの出力は`*grep*'バッファに入ります。 ファイル内の対応する行を探すには、コンパイルエラーの場合と同様に、 C-x `とRETを使います。

M-x grepに前置引数を指定すると、 ポイントの周りから（探すべき）タグを推測して デフォルトのgrepコマンドにそれを含めます。

M-x grep-findはM-x grepコマンドと同様ですが、 シェルコマンドに与える最初のデフォルトが違います。 findとgrepの両方を実行して、 ディレクトリ木構造下の各ファイルを探索します。 26.15 diredとfindプログラムのfind-grep-diredコマンドも参照してください。

21.3 コンパイルモード

`*compilation*'バッファは、 コンパイル（compilation）モードと呼ばれる特別なメジャーモードになります。 このモードの主な機能は、エラーが起きたソース行を簡単に参照できることです。

C-x `

つぎのコンパイルエラーやgrepのつぎの一致に 対応する箇所を訪れる。

RET

ポイントが位置するエラーメッセージに対応する箇所を訪れる。 このコマンドは、コンパイルバッファで使う。

Mouse-2

マウスでクリックしたエラーメッセージに対応する箇所を訪れる。

`*compilation*'でエラーメッセージにポイントを持っていって RET（compile-goto-error）を打鍵すれば、 そのエラーの原因となったソースを訪問できます。 あるいは、エラーメッセージをMouse-2でクリックしますが、 このときは、あらかじめ`*compilation*'バッファに 切り替えておく必要はありません。

コンパイラのエラーメッセージを順番に解析するには、 C-x `（next-error）と打鍵します。 C-xに続く文字は、シングルクォートではなく バッククォート、すなわち、『アクサングレーブ』です。 このコマンドは`*compilation*'だけでなく、 すべてのバッファで使用可能です。 このコマンドは、一方のウィンドウの先頭にエラーメッセージを表示し、 別のウィンドウにエラーとなったソースコードを表示します。

コンパイル開始後に最初にC-x `を使うと、 最初のエラー箇所に移動します。 続けてC-x `を実行すると、次々にエラー箇所に移動していきます。 RETやMouse-2で特定のエラー箇所に移動したあとに C-x `コマンドを実行すると、その場所のつぎのエラー箇所に移動します。 バッファの末尾に到達してもうエラーメッセージがないと、 C-x `コマンドは失敗し、エラーを通知します。

C-u C-x `は、コンパイルバッファの先頭から解析を始めます。 コンパイルをやり直さずに一連のエラーの解析をもう一度行う方法の1つです。

コンパイル（compilation）モードでは、 SPCキーとDELキーを1画面分のスクロールに、 M-nとM-pを1つつぎ／まえのエラーメッセージへの移動に再定義します。 また、別のソースファイルのエラーメッセージへの移動には、 M-{とM-}コマンドを使えます。

コンパイル（compilation）モードの機能は、 コンパイルマイナ（compilation-minor）モードと呼ばれるマイナモードでも 使えます。 これにより、普通のコンパイルバッファだけでなく任意のバッファ内の エラーメッセージを解析できます。 このマイナモードをオンにするには、 M-x compilation-minor-modeと打鍵します。 すると、メジャーモードのコンパイル（compilation）モードと同様に RETキーとMouse-2を定義します。

バッファの内容が認識できる形式である限り、 コンパイルマイナ（compilation-minor）モードは任意のバッファで動作します。 rloginバッファ（see 節 27.14.6 リモートホストのシェル）では、 コンパイルマイナ（compilation-minor）モードは リモートのソースファイルをFTPで自動的に取ってきます（see 節 12.1 ファイル名）。

21.4 コンパイルのためのサブシェル

Emacsはシェルを使ってコンパイルコマンドを実行しますが、 非対話的なシェルになるようなオプションを指定します。 つまり、シェルはプロンプトを出さずに実行を開始するはずです。 `*compilation*'バッファに通常のシェルプロンプトがぶざまに現れる場合は、 個人のシェル初期化ファイルでプロンプトを無条件に設定していることを 意味します。 （シェル初期化ファイルの名前は、`.bashrc'、`.profile'、 `.cshrc'、`.shrc'などだが、 使っているシェルによってさまざまな場合がある。） シェル初期化ファイルでは、プロンプトがすでに設定されているときだけ プロンプトを再設定するべきです。 たとえば、`csh'では以下のようにします。

if ($?prompt) set prompt = ...

bashでは以下のようにします。

if [ "${PS1+set}" = set ]
then PS1=...
fi

読者のシェル初期化ファイルには、対話的なシェルに対してだけ 本来は設定するべきことがまだあるかもしれません。 同じ方法を用いて、それらを状況に応じて設定するようにできます。

MS-DOS『オペレーティングシステム』では、 非同期のサブプロセスを使えません。 対応策として、MS-DOSではM-x compileは コンパイルコマンドを同期的に実行します。 その結果、Emacs上で他の作業を行うには、 コンパイルコマンドの終了を待つ必要があります。 See 節 C. EmacsとMS-DOS。

21.5 Emacs下でのデバッガの実行

GUD（Grand Unified Debugger、大統一デバッガ）ライブラリは、 Emacsからさまざまなデバッガへのインターフェイスを提供します。 フリーソフトウェアであるGDBをお勧めしますが、 DBX、SDB、XDBを持っているならばそれらを使うこともできます。 GUDは、Perlのデバッグモード、 PythonのデバッガPDB、JavaデバッガJDBに対するインターフェイスにもなります。

21.5.1 GUDの起動		How to start a debugger subprocess.
21.5.2 デバッガの操作		Connection between the debugger and source buffers.
21.5.3 GUDのコマンド		Key bindings for common commands.
21.5.4 GUDのカスタマイズ		Defining your own commands for GUD.

21.5.1 GUDの起動

デバッガを開始するコマンドはいくつかあり、 それぞれ、特定のデバッガに対応しています。

M-x gdb RET file RET

EmacsのサブプロセスとしてGDBを実行する。 このコマンドは、GDBへの入出力用のバッファを新たに作り、 そのバッファへ切り替える。 GDBバッファが既存の場合は、そのバッファへ切り替えるだけ。

M-x dbx RET file RET

同様に、GDBのかわりにDBXを実行する。

M-x xdb RET file RET

同様に、GDBのかわりにXDBを実行する。 ソースファイルを探索するディレクトリ群を指定するには、 変数gud-xdb-directoriesを使う。

M-x sdb RET file RET

同様に、GDBのかわりにSDBを実行する。

SDBのバージョンによっては、メッセージにソースファイル名を 含めないものがある。 そのようなSDBを使う場合には、GUDがソースコードから関数を探せるように 正しいタグテーブル（see 節 20.13 タグテーブル）が必要である。 タグテーブルを訪問していなかったり、 タグテーブルに当該関数がなかったりすると、 `The sdb support requires a valid tag table to work'という メッセージが表示される。 このような場合には、作業ディレクトリに正しいタグファイルを生成してから やり直す。

M-x perldb RET file RET

Perlプログラムfileをデバッグするために Perlインタープリタをデバッグモードで実行する。

M-x jdb RET file RET

fileをデバッグするためにJavaデバッガを実行する。

M-x pdb RET file RET

fileをデバッグするためにPythonデバッガを実行する。

これらのコマンドは引数を1つ、 つまり、デバッガを起動するコマンド行を取ります。 もっとも単純な場合は、デバッグしたい実行ファイルの名前を指定します。 デバッガに指定できるオプションを使うこともできます。 しかし、シェルのワイルドカードや変数名は使えません。 GUDは、`-'で始まらない最初の引数をデバッグする実行ファイル名であると 仮定します。

Emacsはデバッガプロセスを一度に1つだけ実行できます。

21.5.2 デバッガの操作

GUDの下でデバッガを実行すると、 デバッガは通常の入出力にEmacsバッファを使います。 このバッファをGUDバッファと呼びます。 デバッガはEmacsバッファでファイルを訪問して、 プログラムのソースファイルを表示します。 このようなバッファの1つに矢印（`=>'）が表示され、 現在実行している行を表示します。 このバッファでポイントを動かしても矢印は動きません。

ソースファイルを表示したバッファでは、いつでもソースファイルを編集できます。 矢印はファイルのテキストの一部ではなく、画面上に表示されているだけです。 ソースファイルを変更するとき、 行を挿入／削除すると矢印の表示位置情報が失われることに注意してください。 GUDには、変更前のデバッガメッセージから変更後の対応する行番号を知る術は ありません。 また、デバッガにソースの変更を反映するには、 プログラムを再コンパイルしてから再実行する必要があります。

お好みならば、シェル（shell）モードの変形を用いた デバッガバッファを介して、デバッガプロセスを完全に制御することもできます。 こうすれば、デバッガのすべてのコマンドを利用でき、 シェル（shell）モードの履歴機能を用いて コマンドを繰り返し実行できます。 See 節 27.14.3 シェルモード（Shellモード）。

21.5.3 GUDのコマンド

GUD対話バッファはシェル（shell）モードの変形を使うので、 シェル（shell）モードのコマンドを使えます（see 節 27.14.3 シェルモード（Shellモード））。 GUDモードでは、ブレークポイントの設定と解除、スタックフレームの選択、 プログラムのステップ実行などのコマンドもあります。 これらのコマンドはGUDバッファでもそれ以外でも使えますが、 キーバインドは異なります。

ブレークポイントコマンドは、普通、ソースファイルのバッファで使います。 というのは、ソース上でブレークポイントを設定／解除するのが自然だからです。 以下はブレークポイントを設定するグローバルコマンドです。

C-x SPC

ポイントがあるソース行にブレークポイントを設定する。

以下はその他のGUDモード特有のコマンドです。 C-cで始まるキー列は、GUD対話バッファだけで使えます。 C-x C-aで始まるキー列は、 GUD対話バッファとソースファイル（のバッファ）の両方で使えます。

C-c C-l

C-x C-a C-l

GUDバッファで参照した最後の行を別のウィンドウに表示する （つまり、最新の実行位置メッセージが指す行を表示する）。 これは、コマンドgud-refreshを実行する。

C-c C-s

C-x C-a C-s

ソースコード1行分を実行する（gud-step）。 その行に関数呼び出しが含まれる場合は、呼び出された関数に入ってから停止する。

C-c C-n

C-x C-a C-n

ソースコード1行分を実行し、関数呼び出しでも 停止せずにフルスピードで実行する（gud-next）。

C-c C-i

C-x C-a C-i

機械語1命令を実行する（gud-stepi）。

C-c C-r

C-x C-a C-r

停止位置を指定せずに実行を継続する。 プログラムの実行は、ブレークポイントに出会う、 プログラムが終了する、 デバッガが監視しているシグナルを受け取るまで実行を継続する。

C-c C-d

C-x C-a C-d

現在のソース行にブレークポイントがあるならばそれを削除する （gud-remove）。 GUD対話バッファでこのコマンドを使うと、 プログラムが最後に停止した行に適用される。

C-c C-t

C-x C-a C-t

現在のソース行に一時的なブレークポイントを設定する。 GUD対話バッファでこのコマンドを使うと、 プログラムが最後に停止した行に適用される。

上にあげたコマンドは、（GUDから使える）すべてのデバッガに共通です。 GDBやDBX（のあるバージョン）では、さらに以下のコマンドも使えます。

C-c <

C-x C-a <

1つ外側のスタックフレームを選択する（gud-up）。 これは`up'コマンドと等価。

C-c >

C-x C-a >

1つ内側のスタックフレームを選択する（gud-down）。 これは`down'コマンドと等価。

GDBを使う場合には以下のコマンドも使用できます。

TAB

GDBでは、シンボル名を補完する（gud-gdb-complete-command）。 このキーはGUDの対話バッファでだけ使える。 また、GDBのバージョンは4.13以降であること。

C-c C-f

C-x C-a C-f

あらかじめ選択したスタックフレームから戻る （あるいは、他の理由で停止する）までプログラムを実行する。

これらのコマンドは、意味がある場合には数引数を反復回数として解釈します。

TABは、補完コマンドとして働くため、 GDBでデバッグしているプログラムへのタブの入力には使えません。 タブを入力するにはC-q TABと打鍵します。

21.5.4 GUDのカスタマイズ

GUDが実行を開始すると、 GDBの場合はgdb-mode-hook、 DBXの場合はdbx-mode-hook、 SDBの場合はsdb-mode-hook、 XDBの場合はxdb-mode-hook、 Perlのデバッグモードの場合はperldb-mode-hook、 PDBの場合はpdb-mode-hook、 JDBの場合はjdb-mode-hookのフックを実行します。 これらのフックを使って、デバッガの対話バッファ用に 自前のキーバインドを定義できます。 See 節 28.2.3 フック。

以下は、特定のコマンド文字列をデバッガに送るコマンドを定義し、かつ、 そのコマンドに対するキーバインドをデバッガの対話バッファに設定する 便利な方法です。

(gud-def function cmdstring binding docstring)

これは、デバッガプロセスにcmdstringを送る functionという名前のコマンドを定義し、 そのコマンドの説明文字列をdocstringとします。 このように定義したコマンドは、どのバッファでも使えます。 bindingがnil以外の場合、 gud-defはGUDバッファのモードに対しては このコマンドをC-c bindingにバインドし、 それ以外に対してはC-x C-a bindingにバインドします。

コマンド文字列cmdstringには、 functionが呼び出されたときにデータが埋め込まれる `%'系列を含めることもできます。

`%f'

現在のソースファイルの名前。 カレントバッファがGUDバッファだった場合には、 『現在のソースファイル』とは プログラムが停止した箇所に対応するソースファイル。

`%l'

現在のソース行番号。 カレントバッファがGUDバッファだった場合には、 『現在のソース行番号』とは プログラムが停止した箇所に対応するソースファイルの行番号。

`%e'

ポイント位置あるいはポイントに隣接する Cの左辺値か関数呼び出し式。

`%a'

ポイント位置あるいはポイントに隣接する 箇所の16進数表記アドレス。

`%p'

functionを呼ぶときに指定された数引数を10進値表記したもの。 数引数なしで呼ばれた場合、`%p'は空文字列。

cmdstringで`%p'を使用しなければ、 定義しようとしているfunctionは数引数を無視する。

21.6 Lisp式の実行

Emacsには、LispやSchemeのための異なったメジャーモードがいくつかあります。 これらは編集コマンドという意味では同じですが、 Lisp式を実行するコマンドが異なります。 各モードには固有の目的があります。

emacs-lispモード

このモードはEmacs Lispで実行するプログラムのソースファイル編集用。 このモードでは、現在の関数定義を評価するC-M-xを定義する。 see 節 21.7 Emacs用のLispコードのライブラリ。

lisp対話モード（Lisp Interaction mode）

このモードはEmacs Lispの対話セッション用。 ポイントの直前のS式を評価し、その値をバッファに挿入するC-jを定義する。 see 節 21.9 lisp対話バッファ。

lispモード

このモードはEmacs Lisp以外のLispで実行するプログラムのソースコード編集用。 このモードでは、 現在の関数定義を下位のLispプロセスに送るC-M-xを定義する。 see 節 21.10 外部Lispの実行。

下位lispモード（Inferior Lisp mode）

このモードは下位Lispプロセスとの対話セッション用。 このモードは、lispモードとシェル（shell）モード（see 節 27.14.3 シェルモード（Shellモード）） の特別な機能の組み合わせ。

schemeモード

lispモードと同様だが、Schemeプログラム編集用。

下位Schemeモード（Inferior Scheme mode）

このモードは下位のSchemeプロセスとの対話セッション用。

Lispプログラム用の編集コマンドの大部分は事実上どこでも使えます。 See 節 20. プログラムの編集。

21.7 Emacs用のLispコードのライブラリ

Emacs編集コマンドのLispコードは、習慣的に`.el'で終る名前の ファイルに格納されています。 これらの拡張子は、 emacs-lispモードで編集するようにEmacsに指示します （see 節 21.6 Lisp式の実行）。

Emacs Lispコードのファイルを実行するには、 M-x load-fileを使います。 このコマンドは、ミニバッファでファイル名を読み取り、 そのファイルの内容をLispコードとして実行します。 あらかじめファイルを訪問しておく必要はありません。 いずれにしても、このコマンドはディスク上のファイルを読むのであって、 Emacsバッファのテキストを読むのではありません。

LispコードのファイルをEmacs Lispライブラリのディレクトリに置いておけば、 そのファイルはM-x load-libraryでロードできます。 プログラムからは、load-libraryを呼んでロードするか、あるいは、 より基本的な類似の関数で余分な引数も指定できるloadでロードします。

M-x load-libraryがM-x load-fileと異なる点は、 一連のディレクトリについて3つのファイル名を順に調べるということです。 引数がlibだとすると、3つのファイル名とは、 `lib.elc'、`lib.el'、そして最後に`lib'です。 `lib.elc'というファイルが存在すれば、 これは習慣として`lib.el'をコンパイルしたものです。 コンパイル済みのファイルはロードと実行が速いので、 こちらをロードするほうが有利です。

load-libraryが`lib.elc'よりも新しい `lib.el'をみつけると、警告を出力します。 というのは、`.el'ファイルを変更後に再コンパイルし忘れている 可能性があるからです。

load-libraryの引数は、通常、それ自体では 正しいファイル名でないことが多いため、ファイル名の補完はできません。 もちろん、このコマンドを使うとき、 指定すべき正確なファイル名を普通は知らないでしょうが。

M-x load-libraryが探索するディレクトリの順番は、 変数load-pathで指定します。 その値は、ディレクトリ名の文字列から成るリストです。 リストのデフォルト値には、Emacs自身のLispコードを収めたディレクトリが 含まれます。 個人用のLispライブラリがあるならば、それらを1つのディレクトリにまとめ、 そのディレクトリ名をload-pathに追加してください。 リスト内のnilはカレントデフォルトディレクトリを表しますが、 リストにnilを加えることはあまり勧められません。 リストにnilが本当に必要だと感じたときには、 それについてはM-x load-fileを実行するのでは いけないだろうかと考えてみてください。

ライブラリの中で定義されているコマンドに対しては、 そのライブラリを自動的にロード（autoload）するように 設定されているので、ほとんどの場合、ライブラリをロードするコマンドを 指定する必要はないでしょう。 ライブラリをロードするためにloadを呼び出すようなコマンドを1つ 試してみてください。 こうすると、「自動的にロードする」という定義が ライブラリ内の実際の定義で置き換わります。

Emacs Lispコードはバイトコードにコンパイルできます。 コンパイルすると、ロードが速くなり、ロードしても必要な記憶容量が少なくなり、 実行も速くなります。 See 節 `バイトコンパイル' in

21.8 Emacs Lisp式の評価

Emacs内で動かすつもりのLispプログラムは、emacs-lispモードで編集しましょう。 ファイル名が`.el'で終っているファイルを編集すると、 自動的にこのモードになります。 一方、lispモードは、他のLispシステム向けのLispプログラムを編集する ためのモードです。 陽にemacs-lispモードに移るには、コマンドM-x emacs-lisp-modeを使います。

Emacs内で動くプログラムのテストには、 Emacsバッファにあるプログラムの一部を評価すると便利です。 たとえば、Lispの関数定義のテキストを変更してからその定義を評価すると、 それ以降にその関数を呼び出すと使われるようにインストールされます。 Lisp式を評価すると非対話的な（コマンドではない）関数を起動できるので、 どんな種類の編集作業にも便利です。

M-:

ミニバッファで1つのLisp式を読み取り、それを評価し、 その値をエコー領域に表示する （eval-expression）。

C-x C-e

ポイントの直前のLisp式を評価し、その値をエコー領域に表示する （eval-last-sexp）。

C-M-x

ポイントを含むか直後にある関数定義（defun）を評価し、 その値をエコー領域に表示する（eval-defun）。

M-x eval-region

リージョン内のすべてのLisp式を評価する。

M-x eval-current-buffer

バッファ内のすべてのLisp式を評価する。

M-:（eval-expression）は、Lisp式を対話的に評価する もっとも基本的なコマンドです。 これは、ミニバッファで式を1つ読み取りますから、 バッファの内容に関係なくバッファ内でどんな式でも実行できます。 式が評価されたあとは、 M-:を打鍵したときのカレントバッファが、ふたたびカレントバッファになります。

emacs-lispモードでは、キーC-M-xはコマンドeval-defunにバインド されています。 このコマンドはポイントを含むか直後にある関数定義を Lisp式として解析し評価します。 その値はエコー領域に表示されます。 このコマンドは、関数定義のテキストの変更を Lisp環境に反映するのに便利です。

C-M-xはdefvar式を特別扱いします。 通常、変数にすでに値が定義されている場合には、 defvar式を評価しても何もしません。 しかし、C-M-xは、defvar式で指定されている 初期値に変数の値を戻します。 この特別な機能は、Lispプログラムをデバッグするときに便利です。

コマンドC-x C-e（eval-last-sexp）は、 ポイントのまえにあるLisp式を評価し その値をエコー領域に表示します。 このコマンドはemacs-lispモードだけでなく、 すべてのメジャーモードで使えます。 このコマンドは、defvarを特別扱いしません。

C-M-x、C-x C-e、M-:に数引数を指定すると、 値をエコー領域に表示するかわりにカレントバッファのポイント位置に挿入します。 引数の値は関係ありません。

バッファでLisp式を評価するもっとも一般的なコマンドはeval-regionです。 M-x eval-regionは、リージョン内の1つ以上のLisp式を解析して、 それらを1つずつ順に評価します。 M-x eval-current-bufferも同様ですが、バッファ全体を評価します。 これは、 テスト準備が整ったLispコードのファイルの内容を取り込むうまい方法です。 個々の関数のバグを発見して修正したら、 変更した関数それぞれにC-M-xを使います。 これによって、Lispの環境とソースファイルが一致します。

21.9 lisp対話バッファ

Emacsが動き始めたときに選択されるバッファ`*scratch*'は、 Emacs内でLisp式を対話的に評価するためのものです。

`*scratch*'バッファを使うもっとも簡単な方法は、 Lisp式を挿入してから各式の末尾でC-jと打つことです。 このコマンドは、ポイントの直前のLisp式を読み取り、 それを評価し、その値を表示形式でポイントのまえに挿入します。 この結果は、評価した式とその値の完全なtypescript (34)です。

`*scratch*'バッファのメジャーモードは lisp対話（lisp interaction）モードであり、 C-jのバインディングを除けば emacs-lispモードと同じです。

この機能が存在する理由を説明しましょう。 Emacsが実行を開始すると何かしらバッファが必要です。 しかし、ファイルを訪問するたびに新たにバッファが作られるので、 このバッファはファイルを編集するのには適しません。 最初のバッファをLispインタープリタのtypescriptにするというのが 作者が考えついたもっともよい方法でした。 M-x lisp-interaction-modeと打つと、 カレントバッファはlisp対話（lisp interaction）モードになります。

Emacs Lisp式を対話的に評価する別の方法は、 下位emacs-lispモードを使うことです。 このモードは、シェル（shell）モード（see 節 27.14.3 シェルモード（Shellモード））に似た インターフェイスでEmacs Lisp式を評価できます。 M-x ielmと打てば、 下位emacs-lispモードを使う`*ielm*'バッファが作られます。

21.10 外部Lispの実行

Emacsには他のLispシステム上でプログラムを実行する機能があります。 LispプロセスをEmacsの下位プロセスとして実行し、 それに式を渡して評価させることができます。 また、Lispプログラムを編集するEmacsバッファの中で変更した 関数定義をそのまま下位のLispプロセスに渡すこともできます。

下位のLispプロセスを実行するには、M-x run-lispと打ちます。 このコマンドは、シェルコマンドとしてlispと入力するのと同じ lispという名前のプログラムを実行し、 プログラムの入出力は`*lisp*'という名前のEmacsバッファを 介してやりとりされます。 つまり、Lispからの『端末出力』はバッファに入りポイントを進め、 Lispへの『端末入力』はバッファのテキストから取られます。 （実行したいLisp実行ファイルの名前を変えるには、 変数inferior-lisp-programを設定する。）

Lispに入力を与えるには、バッファの末尾に移動してから入力を打鍵し、 最後にRETを打ちます。 `*lisp*'バッファは下位lisp（inferior lisp）モードになっていて、 シェル（shell）モード（see 節 27.14.3 シェルモード（Shellモード）） のほとんどの機能にlispモードの特別な特性を組み合わせています。 サブプロセスに1行を送るというRETの定義は、 シェル（shell）モードの機能の1つです。

外部Lispで実行するプログラムのソースファイルにはlispモードを使います。 このモードはM-x lisp-modeで選択できます。 また、ほとんどのLispシステムで使われる `.l'(35) や`.lsp'や`.lisp'で終る名前のファイルには このモードが自動的に使われます。

実行中のLispプログラムの関数を編集しているとき、 変更した定義を下位のLispプロセスに送るもっとも簡単な方法は キーC-M-xです。 lispモードでは、このキーは関数lisp-eval-defunを実行します。 この関数は、ポイントの周りや直後の関数定義を探し、 それをLispプロセスの入力へ送ります。 （Emacsはカレントバッファが何であるかに関わりなく、 どんな下位プロセスにも入力を送ることができる。）

C-M-xコマンドの （任意のLispシステムで実行するプログラムの編集用）lispモードでの意味と （Emacsで実行するLispプログラムの編集用）emacs-lispモードでの意味を 比較してみましょう。 どちらのモードでもポイントを含む関数定義をインストールしますが、 関連するLisp環境がどこにあるかに応じて、その方法は異なります。 See 節 21.6 Lisp式の実行。