[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1. 序文

GNU Emacsテキスト・エディタの大部分はEmacs Lispというプログラミング言語で 書かれています。新しいコードをEmacs Lispで書いてエディタの拡張部分として インストールすることができます。しかし、Emacs Lispは単なる"拡張言語" 以上のものです。Emacs Lispはそれ自身でも完全なコンピュータ・プログラ ミング言語なのです。ほかのプログラミング言語と同じように使うことができるの です。

Emacs Lispはエディタ内で使用するために設計されていますから、ファイルや、 バッファ、ディスプレイ、サブプロセスなどを扱う機能だけでなく、テキストを スキャンしたりパースしたりするための特別な機能もあります。Emacs Lispは編 集機能と密接に統合されていますから、編集コマンドはLispプログラムからも簡 単に呼ぶことのできる関数ですし、カスタマイズ用のパラメータは普通のLisp変 数です。

本マニュアルでは、Emacsを編集作業に使用することにかなり精通していること を前提にして、Emacs Lispについて説明します(このあたりの基本情報につい てはThe GNU Emacs Manualを参照のこと)。一般的に言って、前の方の章 では多くのプログラミング言語にもあるようなEmacs Lispの機能について説明し、 後ろの方の章ではEmacs Lisp独特の機能や、編集作業に特に関連する機能につい て説明します。

本版は第2.4版です。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.1 警告

本マニュアルは数多くの草稿を経ています。だいたい完全ですが、完全無欠とい うわけではありません。(たとえばほとんどの個々のモードのように)2次的であ ると判断したか、あるいはまだ書かれるべきではないという理由で、カバーされ ていない話題も少しあります。そういったものを完全に取り扱うことはできない ので、数箇所を意図的に手をつけないまま残してあります。これには、VMSでの 使用法に関する多くの情報も含まれます。

このマニュアルはカバーしてある範囲内では完全に正確であるべきです。 ですから、具体例や説明文から、章節の順番に至るまで、 書かれているどのようなことに関しても批判を受け付けます。 もし、何かわかりにくいことがあったり、マニュア ルでカバーされてないことを知るために、ソースを見なければならなかったり、 実験しなければならなかったりするなら、おそらく、マニュアルは修正した方が いいでしょう。ぜひとも教えてください。

コメントと訂正は下記へメールしてください。(1)

 
bug-lisp-manual@prep.ai.mit.edu

このリストへのメールは、誰かがその訂正を適用すると決定するまで、未読とし てためておきます。アップデートするのに数ヵ月、ときには数年かかります。で すから、返答がないということに他意はないと思ってください。メールは、 ちゃんと時が来れば作業します。もっと速くEmacsメンテナと連絡を取りたい人 は、bug-gnu-emacs@prep.ai.mit.eduにメールしてください。

 
 --Bil Lewis, Dan LaLiberte, Richard Stallman

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.2 Lispの歴史

Lisp (LISt Processing language リスト処理言語)は、人工知能の研究用にマサ チューセッツ工科大学で1950年代後半にはじめて開発されました。Lisp言語は、編 集コマンドの記述のようなほかの目的にも優れた能力を発揮します。

何年もの間に、数十ものLisp処理系が開発され、それぞれが独特の表現形式をも つに到りました。その多くは、MITのProject MACで1960年代に書かれたMaclisp の影響を受けていました。とうとう、Maclisp子孫の処理系開発者たちが集まって Common Lispと呼ばれるLispシステムの標準を開発しました。

GNU Emacs LispはMaclispに大きく影響を受けています。Common Lispにも少し影 響を受けています。Common Lispを知っている人は、多くの類似性に気づくと思 います。しかし、GNU Emacsの要求メモリを削減するため、省略されたり単純化 されたCommon Lispの機能が多くあります。時には、単純化があまりに過激で、 Common Lispユーザは非常に混乱するかも知れません。時折り、GNU Emacs Lisp がCommon Lispとどう違うか指摘することにします。Common Lispを知らない人は 心配しないでください。本マニュアルは自己充足的ですから。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.3 慣習

本節では、本マニュアルで使用される表記法の慣習について説明します。本節を 飛ばして、後で戻って参照してもよいでしょう。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.3.1 用語

本マニュアルの中では、"Lispリーダ"、"Lispプリンタ"という言葉を、Lisp オブジェクトをテキスト表現から実Lispオブジェクトへ変換、逆変換するLisp内ルー チンを指すのに使います。詳細はSee section 印字表現とリード構文。本マニュア ルを読んでいるあなたを、"プログラマ"と見なし、"あなた"と呼ぶことにし ます。"ユーザ"とは、あなたが書くものも含めたLispプログラムを使う人とし ます。

Lispコードの例はこのようなフォント、形式になっています:(list 1 2 3)。引数やメタ構文上の変数の名前はこのようなフォント、形式になっています: first-number


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.3.2 nilt

Lispではシンボルnilには、三つの別な意味があります。`nil'という名 のシンボルでもあり、論理真理値falseでもあり、空リスト(0個の要素か らなるリスト)でもあります。変数として使用される時は、nilは常に値 nilを持ちます。

Lispリーダが関与するかぎり、`()'`nil'は同一です。同じオブジェ クト、すなわちシンボルnilです。このシンボルにいくつかの異なる書き 方があるのは、すべて人間の読み手のためです。Lispリーダが`()'`nil'を読んだ後は、実際にプログラマがどちらの表現で書いたかを決定す る方法はありません。

本マニュアルでは、空リストとしての意味を強調したいときに()を使用し、 真理値falseとしての意味を強調したいときにnilを使用します。 Lispプログラム内でも使えるよい慣習です。

 
(cons 'foo ())                ; 空リストであることを強調
(not nil)                     ; 真理値falseであることを強調

真理値が求められる文脈中では、nil以外の如何なる値もtrueと見 なされます。しかし、tを使うのが、真理値trueを表すのに好まし い方法です。trueを表す値を選ぶ必要があり、ほかに選択基準がないときは、 tを使いましょう。シンボルtは、常に値tを持ちます。

Emacs Lispでは、niltは、評価すると常に自分自身になる特別 なシンボルです。これは、プログラム中で定数として使用する時、quoteする 必要を無くすためです。値を変更しようとするとsetting-constantエラー になります。See section 変数の値へのアクセス.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.3.3 評価の表記法

評価できるLisp式を形式(form)と呼びます。形式を評価すると常に結果が生成さ れます。結果はLispオブジェクトです。本マニュアル中の例では、 `⇒'で示されます。

 
(car '(1 2))
     ⇒ 1

これは、"(car '(1 2))を評価すると1になる"と読むことができます。

形式がマクロ呼出であるときは、Lispが評価するため、新しい形式に展開します。 展開の結果を`→'で示すことにします。展開した形式の評価の 実際の結果は、示すかもしれないし、示さないかも知れません。

 
(third '(a b c))
     → (car (cdr (cdr '(a b c))))
     ⇒ c

時々、ある形式を説明しやすくするため、同一結果を生成する別の形式を示すこ とがあります。二つの形式の正確な等価性は`≡'で示します。

 
(make-sparse-keymap) ≡ (list 'keymap)

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.3.4 印字の表記法

本マニュアル内の例の多くは、評価されるとテキストを印字します。コード 例をLisp Interactionバッファ(たとえばバッファ`*scratch*')内で実行す ると、印字されるテキストはバッファ内に挿入されます。例をほかの方法で (たとえば関数eval-regionを評価することで)実行すると、印字され るテキストはエコー領域に表示されます。エコー領域に表示されるテキスト は、単一行に切り詰められているということを承知しておいてください。

本マニュアル中の例では、印字されるテキストを、それがどこに行くかには 関係なく、`-|'で示します。形式(ここではbar)を評価して 返ってきた値は別の行に来ます。

 
(progn (print 'foo) (print 'bar))
     -| foo
     -| bar
     ⇒ bar

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.3.5 エラー・メッセージ

エラーを通知する例もあります。これは普通、エラー・メッセージをエコー 領域内に表示します。エラー・メッセージは、`error-->'で始まる行に示す ことにします。`error-->'自身はエコー領域に現れないことに注意して ください。

 
(+ 23 'x)
error--> Wrong type argument: integer-or-marker-p, x

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.3.6 バッファ・テキストの表記法

"実行前"と"実行後"のテキストを用いて、バッファ内のテキストが変更され たことを示す例もあります。このような例では、バッファ名を含んだ破線2本の 間に問題になっているバッファの内容を示します。加えて、`∗'が ポイントの位置を示します。(ポイント用のシンボルはもちろん、バッファのテ キストの一部ではありません。ポイントが位置している2文字の場所 を指します。)

 
---------- Buffer: foo ----------
This is the ∗contents of foo.
---------- Buffer: foo ----------

(insert "changed ")
     ⇒ nil
---------- Buffer: foo ----------
This is the changed ∗contents of foo.
---------- Buffer: foo ----------

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.3.7 説明文の書式

関数、変数、マクロ、コマンド、ユーザ・オプション、特殊形式は、本マニュアル では同一フォーマットで説明されます。説明文の最初の行は、その名前を含み、 もしあれば、それに引数が続きます。 説明文は、時には例とともに、次の行に続きます。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.3.7.1 関数説明のサンプル

関数の説明では、説明する関数の名前は最初に現れます。同一行にパラメータの リストが続きます。パラメータに使用された名前は説明文本文中でも使用されま す。

パラメータ・リスト中にキーワード&optionalが現れたら、それはそれ以降 のパラメータへの引数が省略されるかもしれないことを示します。(省略された パラメータのデフォルトはnilです)。関数を呼ぶ時は&optional を書いてはいけません。

キーワード&rest(常に単一のパラメータが後に続きます)は、任意の数の 引数を後に続けることができることを示します。後に続くこの単一のパラメータ の値は、この引数すべてのリストとなります。関数を呼ぶ時は&restを書 いてはいけません。

以下は、架空の関数fooの説明文です。

Function: foo integer1 &optional integer2 &rest integers

関数foointeger2からinteger1を引き、その後、その結果に 残りの引数すべてを加えます。integer2が与えられなかった場合、19とい う値がデフォルトとして使用されます。

 
(foo 1 5 3 9)
     ⇒ 16
(foo 5)
     ⇒ 14

より一般的に書くと、

 
(foo w x y…)
≡
(+ (- x w) y…)

型名を含んだ名前(例、integerinteger1buffer)をもつ パラメータは、その型であることが期待されています。型の複数形(例、 buffers)はよく、その型のオブジェクトのリストを意味します。 objectという名前のパラメータは任意の型でよいこと意味します(Emacs オブジェクト型のリストはSee section Lisp のデータ型)。ほかの種類の名前を持った パラメータは、関数の説明文の中で具体的に論じます。いくつかの関数のパラメー タに共通するものを、節の冒頭で説明している場合もあります。

optional引数やrest引数のより完全な説明はSee section ラムダ式

コマンド、マクロ、特殊形式の説明文は、`Function'という言葉がそれぞれ、 `Command'、`Macro'、`Special Form'という言葉に置き換えられることを 除けば同じ書式です。コマンドとは単に、対話的に呼び出されることが許される 関数のことです。マクロは、引数を関数とは違うやり方で処理しますが(引数は 評価されない)、同様に示します。

特殊形式の説明文は、オプション引数や繰り返し引数を指定するために、もっと 複雑な記述法を使用しています。なぜなら、特殊形式は、引数リストをもっと複 雑な方法で別個の引数に展開することができるからです。 `[optional-arg]'は、optional-argがオプショ ンであることを意味し、`repeated-args…'は0個以上の引数で あることを意味しています。いくつかの引数がさらに深いレベルのリスト構造に グループ化されているときは、括弧が使われます。例:

Special Form: count-loop (var [from to [inc]]) body

この架空の特殊形式は、body形式を実行するループを作り、繰り返しのた びに変数varをインクリメントします。最初の繰り返しでは、変数は、値 fromを持ち、以後の繰り返しでは、1(incが与えられていればその 値)づつインクリメントされます。もし、bodyを実行する前にvartoに等しければ、ループを抜けます。例:

 
(count-loop (i 0 10)
  (prin1 i) (princ " ")
  (prin1 (aref vector i)) (terpri))

fromtoが省略された場合、varはループが始まる前に nilに束縛されます。繰り返しの冒頭で、もしvarnilで ない場合は、ループを抜けます。例:

 
(count-loop (done)
  (if (pending)
      (fixit)
    (setq done t)))

この特殊形式では、引数fromtoはオプションですが、両方ともあ るか、両方ともないか、どちらかでなければなりません。もし両方ともあれば、 incを指定することもできます。これらの引数は、引数varが あるリストにグループ化されます。これはbodyと区別するためで、 bodyは形式の残りの要素すべてを含みます。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.3.7.2 変数説明のサンプル

変数(variable)とは値をもつことができる名前のことです。どんな変数も ユーザがセットすることができますが、ユーザが変更できることがはっきり指定 されている変数がいくつかあります。それらをユーザ・オプション(user options)と呼びます。普通の変数とユーザ・オプションは、引数がないことを 除き、関数の場合と似た書式を使って説明されています。

架空のelectric-future-map変数の説明文。

Variable: electric-future-map

この変数の値はElectric Command Futureモードで使われる全キーマップです。 このマップ内の関数で、まだ実行しようとは思っていないコマンドを編集するこ とができます。

ユーザ・オプションの説明文も、`Variable'が`User Option'に置き換えられ る以外は、同じ書式です。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.4 謝辞

本マニュアルは、数年間にわたる努力の末、Robert Krawitz、Bil Lewis、Dan LaLiberte、Richard M. Stallman、Chris Welty、及びGNU manual groupのボラ ンティアによって書き上げられました。Robert J. Chassellは、Warren A. Hunt, Jr. of Computational Logic, Inc.の手配で、Defense Advanced Research Projects Agency, ARPA Order 6082のサポートを受け、マニュアルを 監修、編集するのを手伝ってくれました。

訂正をしてくれた人々:Karl Berry, Jim Blandy, Bard Bloom, Stephane Boucher, David Boyes, Alan Carroll, Richard Davis, Lawrence R. Dodd, Peter Doornbosch, David A. Duff, Chris Eich, Beverly Erlebacher, David Eckelkamp, Ralf Fassel, Eirik Fuller, Stephen Gildea, Bob Glickstein, Eric Hanchrow, George Hartzell, Nathan Hess, Masayuki Ida, Dan Jacobson, Jak Kirman, Bob Knighten, Frederick M. Korz, Joe Lammens, Glenn M. Lewis, K. Richard Magill, Brian Marick, Roland McGrath, Skip Montanaro, John Gardiner Myers, Thomas A. Peterson, Francesco Potorti, Friedrich Pukelsheim, Arnold D. Robbins, Raul Rockwell, Per Starback, Shinichirou Sugou, Kimmo Suominen, Edward Tharp, Bill Trost, Rickard Westman, Jean White, Matthew Wilding, Carl Witty, Dale Worley, Rusty Wright, and David D. Zuhn.


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by Yasutaka SHINDOH on September, 29 2006 using texi2html 1.76.