Emacs Lispは、GNU EmacsとXEmacsテキストエディタ（この記事ではあわせて Emacs と呼ぶ）で使われているLispプログラミング言語の方言である。Emacs組込みの編集機能のうち、C言語で書かれた部分以外のほとんどを実装するのに使われている。また、利用者によるEmacsのカスタム化や拡張のために用いられる。Lisp処理系で、もっとも使われている言語である。Emacs Lispは、UnixのBourne Shell、Python、Perl、scsh、GNU Guile などのようなスクリプト言語として使うこともでき、コマンド行や実行ファイルからも呼び出せる。バッファや移動コマンドのような編集機能は、Lispの機能を補いバッチ・モードで動作する。Emacs Lispは、ときに"Elisp"と呼ばれることもある。ただし、この呼び方は同名の無関係な古いLisp方言と混同されるおそれがある。機能でいうと、Common Lispの影響も後にみえるが、Maclisp方言と強い関係がある。プログラミング・メソッドとして、手続き指向プログラミングと関数的プログラミングに対応している。関数をデータとして扱えるなどの強力な機能のため、(TECOを拡張言語としていたオリジナルの) Emacsの書換えにあたり、リチャード・ストールマンは拡張言語としてLispを選んだ。ストールマンがGosling EmacsをGNU Emacsへ書き換えていたとき、Common Lisp とは違ってSchemeは既に存在した。しかし、当時のワークステーションの性能は貧弱であったため、Schemeよりももっと簡単に最適化のできるLisp方言を開発する必要があった。Emacs Lispは、アプリケーション・プログラミングで使われる方言群であるSchemeやCommon Lispとは根本的に異なる。大きな違いの1つは、デフォルトで字句的スコープではなく動的スコープを使うことである。つまり、呼出し関数の局所変数は、呼び出された関数からも参照できるが、定義時のスコープで参照しているのではない。Emacs Lispを書くのがGNU Emacsをカスタム化する唯一の方法ではない。バージョン20以降のGNU Emacsには「カスタム化」機能があり、利用者はグラフィカルなインターフェースによって一般的なカスタム化変数を設定できる。「カスタム化」機能は、比較的単純なものに制限されているものの、利用者の代わりにEmacs Lispのコードを書いてくれる。利用者全員がEmacsの提供する高度な拡張性が必要なわけではないし、またそういう人は自分でEmacs Lispのコードを書けるものだ。Emacs Lispで書いたEmacsの簡単な拡張例をあげよう。Emacsでは、編集領域は、別々の"バッファ"を表示する"ウインドウ"という領域に分かれる。おおざっぱにいえば、バッファとは (大抵はファイルから) Emacsのメモリに読み込んだテキストのかたまりで、テキストファイルとして保存できる。新しいウインドウを開くユーザコマンドは、「codice_1」である。これは、「codice_2」キーを押下した状態で「codice_3」キーを押し、その後単独で「codice_4」キーを押す、ということだ（空白文字は読み易いように示してあるだけで、打ってはいけない）。このキー列はEmacs Lispのcodice_5関数を動かし、普通は新しいウインドウに前のものと同じバッファが表示される。ここでは、その次に有効なバッファを表示するようにしたい、ということにしてみよう。そのためには、利用者は、次のEmacs Lispコードを、既存のEmacs Lispソース・コードや空のEmacsバッファに書く。最初の文 codice_6は、新しい関数codice_7を定義する。これは、codice_5 (前のウインドウ分割関数) を呼び出し、新しいウインドウが別のバッファを表示するようにする。次の文 codice_9 は、「codice_1」というキー列に新しい関数を結び付けなおす。もっと簡単に書く方法もある。Emacs Lispには、"advice"という強力な機能があり、利用者は既存の関数を再定義せずに新しいラッパーを作れるのである。adviceを使うと、上のコードは、次のように再実装できる。これは、codice_5が呼び出されたとき、関数の本体を実行する前に利用者の指定したコードを実行するよう命令している。こういった変更は、たとえば「codice_12」コマンドを使ってコードが"評価"されてはじめて効果が生ずる。Emacsの再コンパイルはおろか再起動さえいらない。Emacsのカスタム化は便利だといわれる所以である。もしEmacsの「立上げファイル」(ふつうは利用者の ホームディレクトリ にある「codice_13」という名前のファイル) にコードを保存すれば、次にEmacsが立ち上がったとき、Emacsはこの拡張を読み込むことになる。Emacs Lispのコードは、「codice_14」という拡張子のファイルに、テキストファイルとして格納される（ただし、利用者の初期設定ファイル名は、Emacs21以前では例外として「codice_13」である）。ファイルが読み込まれると、Emacsプログラムのインタープリタ部分が、関数や変数を読んだり解析したりして、メモリに格納する。そうして、他の編集関数や利用者コマンドで使えるようになる。関数や変数は、自由に修正したり、読み込みなおしたりできる。メモリ空間の節約のため、Emacsの機能の多くは、必要になるまで読込まれない。追加機能一式それぞれは、「ライブラリ」というEmacsコードの集まりで実装されている。たとえば、プログラムソースコードのキーワードの強調用ライブラリやテトリス・ゲームで遊ぶライブラリなどがある。各ライブラリは、ひとつまたは複数のEmacs Lispソース・ファイルで実装される。一部の関数は C言語（以下、単にC）で書いてある。これは「プリミティブ」と呼ばれる（「組込み関数」とか「サブル」ともいう）。プリミティブはLispコードから呼び出すことができ、Cのソース・ファイルを修正し再コンパイルすることでのみ変更できる。GNU Emacsでは、プリミティブを外部ライブラリにすることはできず、Emacs実行形式の一部分となる。XEmacsでは、オペレーティング・システムの動的リンクのサポートを使って、プリミティブを実行時に読み込める。関数をプリミティブで書くのは、Emacs Lispからはアクセスできない外部データやライブラリを用いる必要があったり、CとEmacs Lispで実行速度の差が十分認められるほど頻繁に呼ばれたりする場合である。ただし、Cでのエラーはすぐにセグメンテーション違反やより些細なバグにつながるため、エディタをクラッシュさせるし、Emacs Lispのガベージ・コレクタと正しく相互作用するCのコードを書くことはエラーを引き起こしやすいので、プリミティブで実装されている関数は比較的少数である。Emacs Lispコードの性能は、「バイト・コンパイル」で向上させることができる。Emacs Lispのソース・ファイルをバイトコードという特殊表現に変換するコンパイラがEmacsにはある。Emacs Lispのバイトコード・ファイルの拡張子は、「codice_16」である。ソース・ファイルにくらべると、バイトコードは速く読み込めて、ディスク空間を少ししかとらず、読込み時のメモリーが少なく、速くうごく。バイトコードは、プリミティブよりは遅い。しかし、バイトコードで読み込まれた関数は、簡単に修正したり、再読込みしたりできる。さらに、バイトコード・ファイルは、プラットフォームに依存しない。Emacsについてくる標準的なEmacs Lispコードは、バイトコードで読み込まれるが、利用者の参照用として、対応するソース・ファイルも大抵付いている。利用者の拡張はそれほど大きくもなく、また計算機の負担も小さいので、普通はバイト・コンパイルされない。「cl」パッケージは、Common Lispのサブセットとしてはかなり大規模な実装であり、注目に値する。Emacs Lispは、静的でなく (字句的でもなく) 動的スコープを使う。したがって、もし変数がある関数のスコープで宣言されると、その関数から呼び出されたサブルーチンにおいても有効になる。これはもともとは、利用者のカスタム化のための高度な柔軟性を提供するためのものだった。しかし、動的スコープには短所がいくつかある。第一に、別々な関数の変数間での不本意な相互作用のため、大きなプログラムではバグを簡単に生じやすい。第二に、動的スコープ下での変数アクセスは、字句的スコープのそれより、一般に遅い。そのため、Emacs Lispを字句的スコープに変換する、という計画が立てられたが、まだ完了はしていない。「cl」パッケージのcodice_17マクロは、Emacs Lispのプログラマに効率的な字句的スコープを提供している。「cl」はよく使われているが、codice_17はめったに使われない。Emacs 24 では静的スコープが使えるようになった。Emacs Lispは、他の多くのLisp実装でおこなわれている末尾再帰の最適化をしない。最適化されていない末尾再帰は最終的にスタックオーバーフローに至る可能性がある。

出典:wikipedia