[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Lispコードのファイルをロードするとは、 その内容をLispオブジェクトの形でLisp環境に取り込むことです。 Emacsは、ファイルを探してオープンし、テキストを読み取り、 各フォームを評価し、そしてファイルをクローズします。
ロード関数は、関数eval-current-buffer
がバッファ内の すべての式を評価するように、ファイル内のすべての式を評価します。 異なる点は、ロード関数は、Emacsバッファ内のテキストではなく ディスク上のファイル内のテキストを読み取って評価することです。
ロードするファイルには、Lisp式のソースコードかバイトコンパイル済みコードが 入っている必要があります。 ファイルの各フォームをトップレベルのフォーム(top-level form)と 呼びます。 ロード可能なファイル内のフォーム向けの特別な書式はありません。 ファイル内のどんなフォームでも、バッファに直接打ち込んで評価できます。 (もちろん、ほとんどのコードはこのようにして試したはず。) ほとんどの場合、フォームは関数定義や変数定義です。
Lispコードを収めたファイルをしばしばライブラリ(library)と呼びます。 したがって、『rmailライブラリ』は、rmailモード用のコードを収めたファイルです。 同様に、『Lispライブラリディレクトリ』は、 Lispコードを収めたファイルのディレクトリです。
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Emacs Lispには、ロードのためのインターフェイスがいくつかあります。 たとえば、autoload
は、 ファイルで定義された関数向けに場所を確保するオブジェクトを作成します。 自動ロードする関数を呼び出すと、 ファイルの実際の定義を得るためにファイルをロードします(see 節 14.4 自動ロード)。 require
は、ファイルをすでにロードしていなければロードします (see 節 14.6 機能)。 これらの機構はすべて、最終的には、関数load
を呼び出して動作します。
ファイルを探すために、 load
はまず`filename.elc'という名前のファイル、 つまり、filenameに`.elc'を付加した名前のファイルを探す。 そのようなファイルが存在すれば、それをロードする。 そのような名前のファイルがなければ、 load
は`filename.el'という名前のファイルを探す。 そのファイルが存在すれば、それをロードする。 いずれの名前のファイルもみつからなければ、 最終的に、load
は、なにも付加しないfilenameという名前のファイルを 探し、存在すればそれをロードする。 (関数load
がfilenameを探す手順は賢くない。 (load "foo.el")
を評価すると、 `foo.el.el'という名前のファイルを探してしまう。)
省略可能な引数nosuffixがnil
以外であれば、 `.elc'と`.el'の接尾辞を試さない。 この場合、目的のファイルの正確な名前を指定する必要がある。 正確なファイル名を指定し、かつ、nosuffixにt
を使えば、 `foo.el.el'のようなファイル名を探してしまうことを防げる。
省略可能な引数must-suffixがnil
以外であれば、 load
は、ディレクトリ名を明示していない限り、 ファイル名は`.el'か`.elc'で終るものと仮定する。 filenameにディレクトリ名が明示してなく、かつ、 接尾辞も指定してなければ、load
は接尾辞を必ず付加する。
filenameが`foo'や`baz/foo.bar'のように 相対ファイル名であると、load
は変数load-path
を使って ファイルを探す。 filenameにload-path
に指定した各ディレクトリを付加し、 最初にみつかったファイルをロードする。 デフォルトディレクトリを表すnil
がload-path
に 指定されている場合に限り、カレントディレクトリを試す。 load
は、まず最初のディレクトリで3つの可能な接尾辞を試し、 続いて2番目のディレクトリで3つの可能な接尾辞を試し、 というように行う。 see 節 14.2 ライブラリの探索。
`foo.elc'が`foo.el'より古いという旨の警告を受け取った場合には、 `foo.el'の再コンパイルを考えるべきである。 see 節 15. バイトコンパイル。
(コンパイルしていない)ソースファイルをロードするときには、 Emacsがファイルを訪問する場合と同様に、 load
は文字集合を変換する。 see 節 32.10 コーディングシステム。
nomessageがnil
であると、 ロード中にはエコー領域に `Loading foo...'や`Loading foo...done'のメッセージを表示する。
ファイルをロード中に処理できないエラーに出会うと、ロードを終了する。 autoload
によるロードの場合には、 ロード中に行われた関数定義はすべてもとに戻す。
load
がロードすべきファイルをみつけられないと、 普通、(`Cannot open load file filename'を伴った) エラーfile-error
を通知する。 missing-okがnil
以外であれば、 load
はnil
を返すだけである。
変数load-read-function
を使って、 式を読み取るためにread
のかわりにload
が使う関数を指定できる。 下記参照。
ファイルを正しくロードできるとload
はt
を返す。
load-path
を使わず、接尾辞も付加しない。 ロードするファイル名を正確に指定したい場合にこのコマンドを使う。load
と等価であるが、引数を対話的に読み取る点が異なる。nil
以外であり、さもなければnil
である。load
やeval-region
が、 read
のかわりに使う、式を読み取る関数を指定する。 その関数はread
と同様に引数を1つとること。
通常、この変数の値はnil
であり、 これらの関数がread
を使うことを意味する。
注意: この変数を使うかわりに、
eval-region
の引数read-functionとして 関数を渡す新しい別の機能を使ったほうが見通しがよい。 see 節 8.4 評価(eval)。
Emacs構築時のload
の使い方についての情報は、 See 節 B.1 Emacsの構築方法。
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
EmacsがLispライブラリをロードするときには、 変数load-path
で指定したディレクトリ群でライブラリを探します。
load
でファイルをロードするときに探索する ディレクトリのリストである。 各要素は、(ディレクトリ名である)文字列か (カレント作業ディレクトリを表す)nil
である。load-path
の値は、環境変数EMACSLOADPATH
があれば、 それで初期化します。 さもなければ、デフォルト値は、 Emacsを構築したときに`emacs/src/paths.h'で指定したものです。 そして、リスト内のディレクトリのサブディレクトリをリストに追加して 拡張します。
EMACSLOADPATH
の構文はPATH
と同じです。 `:'(オペレーティングシステムによっては`;')で ディレクトリ名を区切ります。 デフォルトのカレントディレクトリには`.'を使います。 csh
の`.login'ファイルで環境変数EMACSLOADPATH
を 指定する例はつぎのとおりです。
setenv EMACSLOADPATH .:/user/bil/emacs:/usr/local/share/emacs/20.3/lisp |
sh
を使っている場合はつぎのようにします。
export EMACSLOADPATH EMACSLOADPATH=.:/user/bil/emacs:/usr/local/share/emacs/20.3/lisp |
`.emacs'ファイルで、 デフォルトのload-path
の先頭に複数のディレクトリを追加するには、 つぎのようなコードを書きます。
(setq load-path (append (list nil "/user/bil/emacs" "/usr/local/lisplib" "~/emacs") load-path)) |
この例では、Lispコードを、まずカレント作業ディレクトリで探索し、 続いて、`/user/bil/emacs'ディレクトリ、 `/usr/local/lisplib'ディレクトリ、`~/emacs'ディレクトリ、 さらに、標準のディレクトリで探索します。
Emacsのダンプには、load-path
の特別な値を使います。 ダンプ終了時にload-path
の値が未変更(つまり、同じ特別な値)であれば、 ダンプ版Emacsは起動時に、上に述べたように、普通のload-path
の値を 使います。 しかし、ダンプ終了時にload-path
の値が別の値であれば、 ダンプ版Emacsの実行でもその(別の)値を使います。
したがって、`site-init.el'や`site-load.el'で 少数のライブラリをロードするために 一時的にload-path
を変更したい場合には、 load
の呼び出しをlet
で囲んで load-path
をローカルに束縛するべきです。
システムにインストールしたEmacsを実行中は、 load-path
のデフォルト値には、2つの特別なディレクトリ (とそれらのサブディレクトリ)が含まれます。
"/usr/local/share/emacs/version/site-lisp" |
と
"/usr/local/share/emacs/site-lisp" |
です。 前者は、Emacsの特定の版向けにローカルにインストールしたパッケージ用です。 後者は、Emacsの任意の版向けにローカルにインストールしたパッケージ用です。
Emacsのある版向けのパッケージが別の版ではトラブルを引き起こす理由は いくつかあります。 Emacsの互換性のない変更のために更新を必要とするパッケージもあります。 予告なしに変更される可能性のある明文化していない Emacsの内部データに依存するものもあります。 Emacsの新しい版では、パッケージの特定の版と一体になっているものもあり、 その版だけで使うべきです。
Emacsは、起動すると、ディレクトリのサブディレクトリを捜し出して、 それらをload-path
に追加します。 直下のサブディレクトリも複数レベル下のサブディレクトリも load-path
に追加します。
しかし、サブディレクトリすべてを含むわけではありません。 英数字で始まらない名前のサブディレクトリは除外します。 `RCS'という名前のサブディレクトリも除外します。 また、`.nosearch'という名前のファイルを置いた サブディレクトリも除外します。 これらの方法を用いれば、`site-lisp'ディレクトリ下の 特定のサブディレクトリの探索を防げます。
Emacsを構築したディレクトリでEmacsを起動すると、 つまり、正式にインストールしてない実行形式を起動すると、 load-path
には、普通、2つのディレクトリを追加します。 主構築ディレクトリのサブディレクトリ、lisp
とsite-lisp
です。 (どちらも、絶対ファイル名で表される。)
load
と同様にライブラリを探索する。 引数nosuffixの意味はload
と同じであり、 指定した名前libraryに接尾辞`.elc'や`.el'を付加しない。
pathがnil
以外であると、 それはload-path
のかわりに使うディレクトリのリストである。
locate-library
をプログラムから呼び出した場合、 文字列でファイル名を返す。 ユーザーがlocate-library
を対話的に実行した場合、 引数interactive-callはt
であり、これは locate-library
に対してファイル名をエコー領域に表示するように指示する。
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Emacs Lispプログラムが非ASCII文字の文字列定数を含む場合、 Emacs内部では、それらはユニバイト文字列かマルチバイト文字列で表現できます (see 節 32.1 テキスト表現)。 どちらの表現形式を用いるかは、 どのようにファイルをEmacsに読み込んだかに依存します。 マルチバイト表現へ復号化して読んだ場合には、 Lispプログラムのテキストはマルチバイトテキストになり、 その文字列定数はマルチバイト文字列になります。 (たとえば)Lantin-1文字を含むファイルを復号化せずに読むと、 プログラムテキストはユニバイトテキストになり、 その文字列定数はユニバイト文字列になります。 See 節 32.10 コーディングシステム。
結果をより予測可能にするために、 オプション`--unibyte'を指定して起動した場合であっても、 Lispファイルをロードするときには、 Emacsはつねにマルチバイト表現に復号化します。 つまり、非ASCII文字の文字列定数はマルチバイト文字列に変換します。 唯一の例外は、特定のファイルで無変換を指定した場合だけです。
Emacsをこのように設計したのは、 Emacsの起動方法によらずに、 Lispプログラムが予測可能な結果をもたらすようにするためです。 さらに、こうすることで、ユニバイト動作のEmacsであっても、 マルチバイトテキストを使うことに依存したプログラムが動作します。 もちろん、そのようなプログラムは、 default-enable-multibyte-characters
を検査して適切に表現を変換して、 ユーザーがユニバイトテキストとマルチバイトテキストのどちらを 好んでいるか調べるように設計すべきです。
Emacs Lispのほとんどのプログラムでは、 非ASCII文字列はマルチバイト文字列であるということに 気づかないでしょう。 というのは、それらをユニバイトバッファに挿入すると 自動的にユニバイトに変換するからです。 しかしながら、これで違いがでるならば、 Lispファイルの先頭行のコメントに`-*-unibyte: t;-*-'と書くことで、 特定のLispファイルをユニバイトと解釈するように強制できます。 このように指定すると、マルチバイト動作のEmacsであっても、 そのファイルを無条件にユニバイトと解釈します。
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
自動ロード(autoload)機能により、 関数やマクロを定義しているファイルをロードしていなくても、 関数やマクロをLispに登録できます。 関数を初めて呼び出すと、 適切なファイルを読み込んで実際の定義と関連する他のコードを インストールしてから、すでにロードしてあったかのように実際の定義を実行します。
関数を自動的にロードするように設定する方法は2つあります。 autoload
を呼び出すか、あるいは、 ソース内の実際の定義のまえに特別な『マジック』コメントを書きます。 autoload
は自動ロードを行う低レベルの基本関数です。 任意のLispプログラムでいつでもautoload
を呼び出せます。 マジックコメントは、Emacsで使うパッケージ向けに 関数を自動的にロードするように設定するとても便利な方法です。 これらのコメントそのものはなにもしませんが、 コマンドupdate-file-autoloads
に対する指針として働きます。 このコマンドは、autoload
の呼び出しを作成し、 Emacs構築時にそれらを実行するように設定します。
filenameにディレクトリ名や接尾辞.el
や.elc
がなければ、 autoload
はこれらの接尾辞の1つを必ず付加し、 接尾辞を付けないfilenameという名前のファイルはロードしない。
引数docstringは、関数に対する説明文字列である。 通常、これは関数定義そのものの説明文字列と同一であること。 autoload
の呼び出しにおいて説明文字列を指定しておくことで、 関数の実際の定義をロードしなくても説明文を見ることが可能になる。
interactiveがnil
以外ならば、 functionを対話的に呼び出せることを意味する。 つまり、関数の実際の定義をロードしなくても M-xの補完が動作するのである。 完全な対話指定を指定しない。 ユーザーがfunctionを実際に呼び出すまでは必要なく、 呼び出し時点で実際の定義をロードするからである。
普通の関数と同様に、マクロやキーマップも自動的にロードできる。 functionが実際にはマクロならば、typeにはmacro
を指定する。 functionが実際にはキーマップならば、 typeにはkeymap
を指定する。 Emacsのさまざまな部分では、 実際の定義をロードせずにこの情報を知る必要がある。
自動ロードと指定したキーマップは、 プレフィックスキーのバインディングがシンボルfunctionであるときに、 キーを探す過程で自動的にロードする。 キーマップのこれ以外の参照方法では、自動的にロードしない。 特に、変数名がシンボルfunctionと同じであっても、 Lispプログラムで変数の値からキーマップを取得して define-key
を呼び出す場合には、自動的にロードしない。
functionが自動ロードオブジェクトではない 空でない関数定義を有する場合には、 autoload
はなにもせずにnil
を返す。 functionの関数セルが空であったり、 すでに自動ロードオブジェクトである場合には、 つぎのような自動ロードオブジェクトとして関数セルを定義する。
(autoload filename docstring interactive type) |
たとえばつぎのとおり。
(symbol-function 'run-prolog) => (autoload "prolog" 169681 t nil) |
この場合、"prolog"
はロードすべきファイルの名前であり、 169681はファイル`emacs/etc/DOC-version' (see 節 23.1 説明文の基本)内の説明文字列を指す。 t
は関数が対話的であることを示し、 nil
はマクロでもキーマップでもないことを示す。
自動ロード対象のファイルでは、通常、他の定義や 複数の機能を提供したり必要としたりします。 (その内容の評価中のエラーなどで)ファイルを完全にロードできないと、 ロード中に行った関数定義やprovide
の呼び出しをもとに戻します。 そのファイルから自動ロードする任意の関数をつぎに呼び出そうとしたときに、 そのファイルを再度ロードすることを保証するためです。 こうしておかないと、 自動ロードをアボートしたファイルで関数が定義されても、 そのファイルのうしろの部分で定義される その関数に必要なサブルーティンが必ずしもロードされないために その関数が動作しない可能性があるからです。
自動ロード対象のファイルで必要なLisp関数やマクロの定義に失敗すると、 "Autoloading failed to define function function-name"
を 伴ったエラーを通知します。
自動ロードを指定するマジックコメントは、 `;;;###autoload'だけを書いた行であり、 自動ロード対象のソースファイル上で実際の関数定義の直前に必要です。 コマンドM-x update-file-autoloadsは、 対応するautoload
呼び出しを`loaddefs.el'に書き込みます。 Emacs構築時には`loaddefs.el'をロードするので、 autoload
を呼び出します。 M-x update-directory-autoloadsはもっと強力で、 カレントディレクトリのすべてのファイルに対する自動ロード情報を更新します。
同じマジックコメントは、任意の種類のフォームを`loaddefs.el'に コピーできます。 マジックコメントに続くフォームが関数定義でない場合、 そのフォームをそのままコピーします。 構築時にはフォームを実行しても、 ファイルのロード時にはそのフォームを実行しないように マジックコメントを使うこともできます。 そうするには、マジックコメントと同じ行にそのフォームを書きます。 するとそれはコメントなので、ソースファイルをロードするときにはなにもしません。 一方、M-x update-file-autoloadsはそのフォームを`loaddefs.el'に コピーするので、Emacs構築時には実行されるのです。
つぎの例は、マジックコメントを使ってdoctor
を自動ロードする方法です。
;;;###autoload (defun doctor () "Switch to *doctor* buffer and start giving psychotherapy." (interactive) (switch-to-buffer "*doctor*") (doctor-mode)) |
こうすると、`loaddefs.el'ではつぎのようになります。
(autoload 'doctor "doctor" "\ Switch to *doctor* buffer and start giving psychotherapy." t) |
ダブルクォートの直後にバックスラッシュや改行を書く慣習は、 `loaddefs.el'などの あらかじめロードするLispファイルの中だけで使うものです。 これは、make-docfile
に対して、 説明文字列を`etc/DOC'ファイルに書くように指示します。 See 節 B.1 Emacsの構築方法。
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
1つのEmacsセッションにおいて、あるファイルを複数回ロードできます。 たとえば、バッファ内の関数定義を編集して、 関数定義を書き直してインストールし直したあとで、 もとの版に戻したいこともあるでしょう。 これには、もとのファイルを再ロードすればよいのです。
ファイルをロードしたり再ロードするとき、 関数load
やload-library
は、 コンパイルしていないファイルではなく、 バイトコンパイル済みのファイルを自動的にロードすることに注意してください。 ファイルを書き直して保存してから再インストールする場合、 新しい版をバイトコンパイルする必要があります。 さもないと、Emacsは、新しいコンパイルしていないファイルではなく、 バイトコンパイル済みの古いファイルをロードしてしまいます。 そのような場合、ファイルをロードすると、 `(compiled; note, source is newer)'とメッセージを表示して、 再コンパイルするように忠告してきます。
Lispライブラリファイルにフォームを書くときには、 ファイルを複数回ロードする可能性があることを忘れないでください。 たとえば、ライブラリを再ロードするたびに 各変数を再初期化すべきかどうか考えましょう。 defvar
は、初期化済みの変数の値を変更しません。 (see 節 10.5 グローバル変数を定義する。)
連想リストに要素を追加するもっとも簡単な方法はつぎのとおりです。
(setq minor-mode-alist (cons '(leif-mode " Leif") minor-mode-alist)) |
しかし、これでは、ライブラリを再ロードすると、 複数の要素を追加してしまいます。 これを避けるにはつぎのようにします。
(or (assq 'leif-mode minor-mode-alist) (setq minor-mode-alist (cons '(leif-mode " Leif") minor-mode-alist))) |
リストに要素を1回だけ追加するには、 add-to-list
(see 節 10.8 変数値の変更)も使えます。
ライブラリをすでにロードしたかどうか明示的に調べたいこともあるでしょう。 ライブラリ内で以前ロードされたかどうか検査する方法の1つは、 つぎのとおりです。
(defvar foo-was-loaded nil) (unless foo-was-loaded execute-first-time-only (setq foo-was-loaded t)) |
ライブラリで名前付き機能を提供するためにprovide
を使っていれば、 ファイルの始めのほうでfeaturep
を使って、 provide
を以前呼び出したかどうか検査できます。 See 節 14.6 機能。
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
provide
とrequire
は、 ファイルを自動的にロードするためのautoload
の代替手段です。 それらは指定した機能(features)という考え方で動作します。 自動ロードは特定の関数を呼び出すことで起動しますが、 機能はその名前でプログラムが最初に要求したときにロードします。
機能名は、関数や変数などの集合を表すシンボルです。 それらを定義するファイルでは、その機能を提供(provide)します。 それらを使う別のプログラムでは、 その機能を要求(require)することで、 それらが定義されることを確実にします。 こうすると、未ロードであれば定義しているファイルをロードします。
機能を要求するには、機能名を引数にしてrequire
を呼び出します。 require
は、グローバル変数features
を調べて、 目的の機能がすでに提供されているかどうか調べます。 提供されていなければ、適当なファイルから機能をロードします。 このファイルでは、トップレベルでprovide
を呼び出して、 features
に機能を追加するべきです。 そうしないと、require
はエラーを通知します。
たとえば、`emacs/lisp/prolog.el' には、 つぎのコードのようなrun-prolog
の定義が入っています。
(defun run-prolog () "Run an inferior Prolog process, with I/O via buffer *prolog*." (interactive) (require 'comint) (switch-to-buffer (make-comint "prolog" prolog-program-name)) (inferior-prolog-mode)) |
(require 'comint)
は、ファイル`comint.el'が未ロードであると、 そのファイルをロードします。 これにより、make-comint
が定義済みであることを保証します。 普通、機能には、その機能を提供するファイル名からとった名前を付けますから、 require
にファイル名を指定する必要はありません。
`comint.el'ファイルには、つぎのトップレベルの式が入っています。
(provide 'comint) |
これにより、グローバル変数features
のリストに comint
が追加されるので、 これ以降に(require 'comint)
を実行しても、 なにもしないでよいことになります。
ファイルのトップレベルでrequire
を使うと、 そのファイルをロードする場合と同様に、 そのファイルをバイトコンパイルするとき(see 節 15. バイトコンパイル)にも require
には効果があります。 要求したパッケージに、 バイトコンパイラが知っている必要があるマクロが入っている場合です。
トップレベルのrequire
の呼び出しは、 バイトコンパイル中に評価されますが、 provide
の呼び出しは評価しません。 したがって、つぎの例のように、 同じ機能に対するprovide
に続けてrequire
を書くことで、 バイトコンパイルするまえに定義のファイルをロードすることを確実にできます。
(provide 'my-feature) ; バイトコンパイラは無視し、
;
|
コンパイラはprovide
を無視し、 続くrequire
の処理では当該ファイルをロードします。 ファイルのロード時にはprovide
の呼び出しを実行するので、 そのあとのrequire
の呼び出しは、 ファイルをロードするときにはなにもしません。
provide
の呼び出しの直接の効果は、 featureがリストfeatures
に入っていなければ、 featureをリストfeatures
の先頭に入れることである。 引数featureはシンボルであること。 provide
はfeatureを返す。
features => (bar bish) (provide 'foo) => foo features => (foo bar bish) |
自動ロードによってファイルをロードしているとき、 その内容を評価することでエラーになってロードを中止すると、 ロード中に行われた関数定義やprovide
の呼び出しはもとに戻す。 see 節 14.4 自動ロード。
(featurep feature)
を使って) 現在のEmacsセッション内にfeatureが存在するかどうか調べる。 引数featureはシンボルであること。
機能が存在していなければ、require
は、 load
を使ってfilenameをロードする。 filenameを指定しないと、シンボルfeatureの名前を ロードすべきファイル名の基にする。 しかしながら、この場合には、require
は、 接尾辞を必ず付加してfeatureを探す。 featureだけの名前のファイルは探さない。
featureを提供するファイルのロードに失敗すると、 require
はエラー `Required feature feature was not provided'を通知する。
features
のメンバであれば) t
を返す。provide
を呼び出すことでこのリストに追加される。 リストfeatures
内の要素の順番は関係ない。[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
ライブラリでロードした関数や変数を捨てさって 他のLispオブジェクト向けにメモリを回収することができます。 そうするには関数unload-feature
を使います。
defun
、defalias
、 defsubst
、defmacro
、defconst
、defvar
、 defcustom
で定義した関数、マクロ、変数すべてを未定義にする。 そうして、これらのシンボルに以前設定してあった自動ロードの設定を復元する。 (ロード時に、これらをシンボルの属性autoload
に保存している。)
以前の定義に復元するまえに、unload-feature
はremove-hook
を 実行して、ライブラリ内の関数を特定のフックから取り除く。 これらのフックは、`-hook'や`-hooks'で終る名前の変数、および、 loadhist-special-hooks
に入っているものである。 これは、重要なフックにおいて存在しない関数を参照することで Emacsが動作不能になるのを防ぐ。
これらの処置でも誤動作防止には不十分であるときには、 ライブラリで明示的なアンロードフックを定義できる。 feature-unload-hook
を定義してあると、 以前の定義を復元するまえに、 フックを削除する通常の動作のかわりに このフックをノーマルフックとして実行する。 アンロードフックでは、 ライブラリをいったんアンロードすると動作不能になるような ライブラリで変更したグローバルな状態をすべてアンドゥすべきである。
通常、unload-feature
は、他のライブラリが依存している ライブラリのアンロードは拒否する。 (ライブラリaでbをrequire
(要求)していると、 ライブラリaはライブラリbに依存している。) 省略可能な引数forceがnil
以外であると、 依存関係を無視し、任意のライブラリをアンロードできる。
関数unload-feature
はLispで書いてあり、 その動作はload-history
に基づきます。
各要素はリストであり、1つ1つが1つのライブラリを記述する。 リストのCARは文字列であり、ライブラリ名である。 リストの残りは、以下の種類のオブジェクトから成る。
(require . feature)
の形のリストであり、 要求する機能を示す。(provide . feature)
の形のリストであり、 提供する機能を示す。load-history
の値には、CARがnil
であるような 1つの要素があってもよい。 この要素は、ファイルを訪問してないバッファ内でeval-buffer
によって 作られた定義であることを示す。
コマンドeval-region
はload-history
を更新しますが、 訪問先ファイルに対応する要素に、定義されるシンボルを追加するのであって、 要素を置き換えるのではありません。
あらかじめロード済みのライブラリは、load-history
に寄与しません。
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
eval-after-load
を呼び出すと、 特定のライブラリをロードする/してあるときに実行するコードを指定できます。
ライブラリ名libraryはload
の引数に正確に一致する必要がある。 load-path
を探索してインストールするライブラリを探したときに 正しい結果を得るために、libraryにはディレクトリ名を含めないこと。
formでエラーが発生してもロード処理をもとに戻さないが、 formの残りは実行しない。
一般に、よく設計されたLispプログラムはこの機能を使うべきではありません。 Lispライブラリを見通しよくモジュール化して扱うには、 (1)ライブラリの(外部から使うことを意図した)変数を調べて設定し、 (2)ライブラリの関数を呼び出すことです。 (1)を行いたければ、すぐにしてかまいません。 ライブラリをロードするまで待つ必要はありません。 (2)を行うには、ライブラリをロードする必要があります (require
で行うことが好ましい)。
広く使われるプログラムに対する設計基準に合わなくても、 個人のカスタマイズでeval-after-load
を使うのはかまいません。
(filename forms...) |
関数load
は、eval-after-load
を実現するために after-load-alist
を調べる。
[ << ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |