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

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

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 File Variables）。

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

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

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

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

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の両方を実行して、ディレクトリ木構造下の各ファイルを探索します。 Dired and Findのfind-grep-diredコマンドも参照してください。

コンパイルモード
========

*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 Remote Host）では、コンパイルマイナ（compilation-minor）モードはリモートのソースファイルをFTPで自動的に取ってきます（see File Names）。

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

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 MS-DOS。

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

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

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 Tags）が必要である。タグテーブルを訪問していなかったり、タグテーブルに当該関数がなかったりすると、 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つだけ実行できます。

デバッガの操作
-------

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

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

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

GUDのコマンド
--------

GUD対話バッファはシェル（shell）モードの変形を使うので、シェル（shell）モードのコマンドを使えます（see Shell Mode）。 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と打鍵します。

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 Hooks。

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

     (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は数引数を無視する。

Lisp式の実行
========

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

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

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

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

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

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

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

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

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

Emacs編集コマンドのLispコードは、習慣的に.elで終る名前のファイルに格納されています。これらの拡張子は、 emacs-lispモードで編集するようにEmacsに指示します（see Executing 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 Byte Compilation (The Emacs Lisp Reference Manual)。習慣として、ライブラリのコンパイル済みのコードは、ライブラリのソースファイル名にcを付けた名前の別のファイルに入ります。したがって、foo.elのコンパイル済みのコードは、foo.elcに入ります。これが、load-libraryはまず.elcというファイルを探す理由です。

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の環境とソースファイルが一致します。

lisp対話バッファ
==========

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

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

*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 Shell Mode）に似たインターフェイスでEmacs Lisp式を評価できます。 M-x ielmと打てば、下位emacs-lispモードを使う*ielm*バッファが作られます。

外部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 Shell Mode）のほとんどの機能にlispモードの特別な特性を組み合わせています。サブプロセスに1行を送るというRETの定義は、シェル（shell）モードの機能の1つです。

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

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

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