[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
この章にはEmacs Lispの新たな機能の説明ではなく、前章までに説明された 機能を効果的に使用するためのアドバイスが記述されています。
A.1 明確なLispプログラムの記述 | 明確で堅牢なプログラムを書く。 | |
A.2 コンパイルされたコードを速くする | ||
A.3 読みやすい説明文字列を書く | ||
A.4 コメントの書き方 | ||
A.5 Emacsライブラリのヘッダの規約 | ライブラリ・パッケージの標準的なヘッダ。 |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
以下は、広く使用されることを目的とするLispコードを書くときによく犯され る誤りを避けるためのヒントや作法です。
この規則は、Emacs Lispではプリミティブではないが、伝統的なLispでは
primitiveであるものの名前にも(たとえばcadr
であっても)適用されます。
たとえば、いくつものcadr
を定義するうまい方法があります。安全のた
めに、cadr
とせずに、foo-cadr
もしくはmylib-cadr
など
としてください。
ある名前(たとえばtwiddle-files
という名前で)でEmacsの配布に加えら
れるべきだと思われる関数を書いたときも、あなたのプログラムの中でその名前
を使って呼ばないでください。とりあえず、あなたのプログラムの中では
mylib-twiddle-files
と呼んでおいて、その関数をEmacsに加えるよう
`bug-gnu-emacs@prep.ai.mit.edu'宛にメイルを送ってください。
一つの接頭語では不十分である場合は、意味があるのであれば複数の共通な接 頭語を使っても構いません。
接頭語と残りのシンボル名はハイフン`-'で区切ってください。これは Emacs自身やほとんどのEmacs Lispプログラムと一貫します。
provide
関数を用いると便利
です。
require
を使用して
ください。
require
が必
要です。
(eval-when-compile (require 'bar)) |
なお、require
がうまく働くためには、barが(provide '
bar)
を含んでいなければなりません。
このようにすることにより、fooがバイト・コンパイルされるときに barがロードされます。こうしないと、必要なマクロをロードせずに fooをコンパイルしてしまうため、コンパイルされたコードは正しく動 作しなくなります。See section マクロとバイトコンパイル。
eval-when-compile
を用いることにより、コンパイルされたfooが
使用されるときに、barがロードされるのを防ぐことができます。
run-hooks
を用いてフック変数を実行するようにしてください。
See section フック。
framep
、frame-live-p
)
かわりにC-c non-letterというシーケンスを用いてください。 これは主モードのために予約されています。
この規約に従うように、Emacsバージョン18の全ての主モードを変更するのは大 変な作業でした。この規約を守らないことは、その作業を無駄にし、さらにはユー ザにとっても不便です。
ある状況(context)で前置文字以外でESCをバインドすると、その状況での ファンクション・キーによるエスケープ・シーケンスと区別がつかなくなるため、 この規則があります。
whatever-mode
という名前のコマ
ンドを定義し、それを自動ロード(autoload)してください(see section 自動ロード)。
パッケージを単にロードしただけでは目に見える効果がないよう、つまりその効
果を有効にしないように設計してください。そうしてユーザがそのコマンドを起
動することによって効果を有効にします。
next-line
とprevious-line
を使用しないで
ください。ほとんど全ての場合forward-line
の方が便利であり、安
全です。See section テキスト行単位での移動。
特に以下の関数は用いてはいけません。
beginning-of-buffer
, end-of-buffer
replace-string
, replace-regexp
これらの関数のマークを変更するという機能をユーザに対して提供するつもりで はなく、ただ単にポイントを移動したい、もしくは文字列を置き変えたいという のであれば、これらの関数を1、2行の簡単なLispコードで置き換えることができ ます。
ベクタは、要素の挿入や削除が必要でなく(リストだけがこのようなことができ ます)、(最初から最後まで検索するのではなく)不規則にアクセスするような大 きなテーブルには有効です。
princ
よりもmessage
関数の方が適切です。See section エコー領域。
error
(もしくはsignal
)
を呼んでください。関数error
はもとの関数に返りません。
See section エラーを発行する方法。
エラーの通知にmessage
、throw
、sleep-for
もしくは
beep
を使用しないでください。
edit-options
コマンドが行っているように、別のバッファに切り替わっ
た後、ユーザの操作により元に戻るようにしてください。See section 再帰編集。
indent-sexp
)によって字下げしてください。
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
バイト・コンパイルされたLispプログラムの実行速度を改善する方法につい て説明します。
memq
、member
、assq
も
しくはassoc
を使う方が、明示的な繰り返しを使うよりずっと高速です。
これらのプリミティブ検索関数が使えるように、データ構造自体を再検討するの
もよいでしょう。
byte-compile
属性を調べてください。もし
byte-compile
属性がnil
でなければ、その関数は特別扱いさ
れます。
たとえば次のようにすれば、aref
は特別扱いされるが(see section 配列に関する関数)、elt
は特別扱いされないされないことがわかります
(see section シーケンス)。
(get 'aref 'byte-compile) ⇒ byte-compile-two-args (get 'elt 'byte-compile) ⇒ nil |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
説明文字列(documentation string)の書き方の作法について説明します。
説明文字列にその関数や変数の使用法の詳細を加えることもできます。これらの 行も完全な文としてください。ただし、これらはそれが見やすいのであれば、行 詰め(fill)を行ってください。
単に説明文字列全体を行詰めをするのではなく、注意して改行を入れるとずっと 読みやすくなります。説明文字列が長い場合は、話題ごとに空白行で区切ってく ださい。
nil
でない場合は
…" などというようにしてください。こうすることによって、全ての
nil
でない値が等価であることを明確になり、nil
および
nil
でない値がそれぞれ何を意味するのかも明確に示されます。
/
の説明文字列では、2番目の実引数の名前がdivisor
で
あるため、それを`DIVISOR'としています。
たとえばリストやベクタを、変化する文法的要素(subunits)に分解して代表的に 示す場合などは、メタ構文上の変数(meta-syntactic variable)は全て大文字と してください。(29)
forward-char
が対応づけられているキーに置き換えます(この例
では、通常は`C-f'となりますが、ユーザがキー・バインドを変更している
場合は別の文字となります)。See section 説明文字列でのキー・バインドの置換。
説明文字列の表示が遅くなるため、`\\[…]'を何度も何度も使うの は実用的ではありません。主モードの最も重要なコマンドの説明にのみ使用し て、そのモードのキーマップのその他のものの表示には`\\{…}' を使用してください。
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ここに書かれているようにコメントを記述し、字下げを行うことが推奨されま す。
一つのセミコロン(`;')で始まるコメントは、全てソース・コードの右側の
同じ桁に揃えてください。通常これらのコメントは、同じ行のコードが何をする
かを説明するのに用いられます。Lispモードや関連するモードでは、M-;
(indent-for-comment
)コマンドが、自動的に正しい場所にこの`;'
を挿入したり、すでにコメントがある場合はその位置を揃えたりします。
この例およびこれ以降の例はEmacsのソースのものです。
(setq base-version-list ; there was a base (assoc (substring fn 0 start-vn) ; version to which file-version-assoc-list)) ; this looks like ; a subversion |
二つのセミコロン(`;;')で始まるコメントは、コードの字下げと同じ位置 に揃えてください。通常これらのコメントは、それ以降の行の目的や、その位置 でのプログラムの状態を記述します。たとえば、
(prog1 (setq auto-fill-function … … ;; update mode line (force-mode-line-update))) |
(そのパッケージ内でのみ使用されるため)説明文字列を持たない関数には、かわ りにその関数が何を行ないどのように呼ばれるのが正しいかを説明する二つのセ ミコロンから始まるコメントを書くべきです。それぞれの引数の意味とその値を 関数がどのように用いるかを正確に説明してください。
三つのセミコロン(`;;;')で始まるコメントは、左マージンの位置から開始 してください。このようなコメントは、関数定義の外でのそのプログラムの設計 方針を説明する一般的な記述に用いられます。
;;; This Lisp code is run in Emacs ;;; when it is to operate as a server ;;; for other processes. |
三つのセミコロンで始まるコメントのもう一つの使い方は、関数の中の行をコ メント・アウトするものです。コメントが左マージンに残るようにこの目的に 使用します。
(defun foo (a) ;;; This is no longer necessary. ;;; (force-mode-line-update) (message "Finished with %s" a)) |
四つのセミコロン(`;;;;')で始まるコメントは、左マージンの位置から開 始し、プログラムの大きな区切りごとの先頭に用いられます。たとえば
;;;; The kill ring |
M-; (indent-for-comment
)やTAB
(lisp-indent-line
)などのEmacsのLispモードの字下げ命令は、自動的に
この規約に従って字下げを行ないます。See (emacs)Comments section `Manipulating Comments' in The GNU Emacs Manual。
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Emacsバージョン19では、Lispライブラリを段落に分けたり、その作者 などの情報を付加するために特別なコメントの規約を定めています。この節で はこれらの規約について説明します。まず最初に例を示します。
;;; lisp-mnt.el --- minor mode for Emacs Lisp maintainers ;; Copyright (C) 1992 Free Software Foundation, Inc. ;; Author: Eric S. Raymond <esr@snark.thyrsus.com> ;; Maintainer: Eric S. Raymond <esr@snark.thyrsus.com> ;; Created: 14 Jul 1992 ;; Version: 1.2 ;; Keywords: docs ;; This file is part of GNU Emacs. copying permissions… |
1番先頭の行は次の書式です。
;;; file名 --- 説明 |
説明(description)は一行に納めてください。
著作権表示に続いて、数行のヘッダ・コメント(header comment)行 が置かれます。それぞれ`;; header名:'で始まります。以下が header名で使われる規約の表です。
この行には、ライブラリの少なくとも最初の作者の名前とネットワーク・アドレ スを記述します。
複数の作者がいる場合は、次のように;;
とタブ文字で始まる継続
行を用いて記述します。
;; Author: Ashwin Ram <Ram-Ashwin@cs.yale.edu> ;; Dave Sill <de5@ornl.gov> ;; Dave Brennan <brennan@hal.com> ;; Eric Raymond <esr@snark.thyrsus.com> |
この行には、Author行のように、一人分の名前とアドレスもしくは一人分のアド レスのみ、もしくは`FSF'と書きます。この行が省略された場合は、Author 行の作者が管理を行っているものとみなされます。上の例は、maintainer行が冗 長であるため、あまりよい例ではありません。
手で名前を埋め込まなくとも "管理者へmailを送る" Lisp関数を作ること を可能とすることが、`Author'行と`Maintainer'行のもう一つの目 的です。
ネットワーク・アドレスとフル・ネームを両方記述する場合は、必ずネッ トワーク・アドレスを`<…>'で囲ってください。
この行には、最初にファイルを作成した日付を記述します。省略可能です。歴史 的な興味のためだけのためにあります。
個々のLispプログラムにバージョン番号を記録したいのであれば、この行に 記述してください。
この行には、(たとえばこの規約に従うように変更をした場合のように)ライブラ リのあまり内部にかかわらないような(30)変更を行った人の名前を記述してください。
この行には、finder-by-keyword
ヘルプ命令のためのキーワードを記述し
ます。ユーザは、やりたいことから探すときに、あなたのプログラムをこのキー
ワードから探すため、この行は重要です。キーワードを分けるときは、空白文字、
コンマ、もしくはその両方を用います。
少なくとも`Author'と`Keywords'の行は、全てのLispライブラリに 必要です。適切であれば他の行も使用してください。別のヘッダ名の行を加えて も構いません。標準的な意味はないため何の害もありません。
我々は、ライブラリ・ファイルの内容をいくつかに分割するために標準的なコ メントを決めています。以下がその表です。
そのライブラリがどのように働くかを説明する紹介説明の始まりを示します。 著作権許可のすぐ後にあるべきです。
(変更履歴を記述する場合の)ライブラリ・ファイルの変更履歴の始まりを示しま す。Emacsとともに配布されるほとんどLispファイルでは、変更履歴は `ChangeLog'に書かれており、ソース・ファイル中には全く記述されていま せん。したがってこれらのファイルには`;;; Change log:'行はありません。
実際のプログラム・コードの始まりを示します。
これはフッタ行(footer line)で、ファイルの1番最後の行です。このフッ タ行がないことから、ファイルの後部が切り取られたバージョンであることを知 ることができます。
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Yasutaka SHINDOH on September, 29 2006 using texi2html 1.76.