D.1 Emacs Lispコーディングの慣習

以下は幅広いユーザーを意図したEmacs Lispコードを記述する際にしたがうべき慣習です:

• 単なるパッケージのロードがEmacsの編集の挙動を変更するべききではない。コマンド、その機能を有効や無効にするコマンド、その呼び出しが含まれる。

  この慣習はカスタム定義を含むすべてのファイルに必須である。そのようなファイルを慣習にしたがうために修正するのが非互換の変更を要するなら、構うことはないから非互換の修正を行うこと。先送りにしてはならない。

• 他のLispプログラムと区別するための短い単語を選択すること。あなたのプログラム内のグローバルなシンボルすべて、すなわち変数、定数、関数の名前はその選択したプレフィクスで始まること。そのプレフィクスと名前の残りの部分はハイフン‘-’で区切る。Emacs Lisp内のすべてのグローバル変数は同じネームスペース、関数はすべて別のネームスペースを共有するので、これの実践は名前の競合を回避する²¹。他のパッケージから使用されることを意図しない場合にはプレフィクス名前を2つのハイフンで区切ること。

  ユーザーの使用を意図したコマンド名では、何らかの単語がそのパッケージ名のプレフィクスの前にあると便利なことがある。関数や変数等を定義する構文は‘defun’や‘defvar’で始まればより良く機能するので、名前内でそれらの後に名前プレフィクスを置くこと。

  この勧告はcopy-listのようなEmacs Lisp内のプリミティブではなく、伝統的なLispプリミティブにさえ適用される。信じようと信じまいとcopy-listを定義する尤もらしい方法は複数あるのだ。安全第一である。かわりにfoo-copy-listやmylib-copy-listのような名前を生成するために、あなたの名前プレフィクスを追加しよう。

  twiddle-filesのような特定の名前でEmacsに追加されるべきだと考えている関数を記述する場合には、プログラム内でそれを名前で呼び出さないこと。プログラム内ではそれをmylib-twiddle-filesで呼び出して、わたしたちがそれをEmacsに追加するため提案メールを、‘bug-gnu-emacs@gnu.org’に送信すること。もし追加することになったときに、わたしたちは十分容易にその名前を変更できるだろう。

  1つのプレフィクスで十分でなければ、それらに意味があるかぎり、あなたのパッケージは2つか3つの一般的なプレフィクス候補を使用できる。

• 個々のLispファイルすべての終端にprovide呼出を配置すること。Named Featuresを参照のこと。
• 事前に他の特定のLispプログラムのロードを要するファイルはファイル先頭のコメントでそのように告げるべきである。また、それらが確実にロードされるようにrequireを使用すること。Named Featuresを参照のこと。
• ファイルfooが別のファイルbar内で定義されたマクロを使用するが、bar内の他の関数や変数を何も使用しない場合にはfooに以下の式を含めること:

  (eval-when-compile (require 'bar))
  

  これはfooのバイトコンパイル直前にbarをロードするようEmacsに告げるので、そのマクロはコンパイル中は利用可能になる。eval-when-compileの使用によりコンパイル済みバージョンのfooが中古ならbarのロードを避けられる。これはファイル内の最初のマクロ呼び出しの前に呼び出すこと。Compiling Macrosを参照のこと。

• 実行時に本当に必要でなければ、追加ライブラリーのロードを避けること。あなたのファイルが単に他のいくつかのライブラリーなしでは機能しないなら、トップレベルでそのライブラリーを単にrequireしてこれを行うこと。しかしあなたのファイルがいくつかの独立した機能を含み、それらの1つか2つだけが余分なライブラリーを要するなら、トップレベルではなく関連する関数内部へのrequireの配置を考慮すること。または必要時に余分のライブラリーをロードするためにautoloadステートメントを使用すること。この方法ではあなたのファイルの該当部分を使用しない人は、余分なライブラリーをロードする必要がなくなる。
• Common Lisp拡張が必要なら古いclライブラリーではなく、cl-libライブラリーを使うこと。clライブラリーはクリーンなネームスペースを使用しない(定義が‘cl-’で始まらない)。パッケージが実行時にclをロードする場合には、そのパッケージを使用しないユーザーにたいして名前の衝突を起こすかもしれない。

  (eval-when-compile (require 'cl))でコンパイル時にclを使用するのは問題ない。コンパイラーはバイトコードを生成する前にマクロを展開するのでcl内のマクロを使用するには十分である。ただしこの場合においても現代的なcl-libを使用するほうが良い。

• メジャーモードを定義する際にはメジャーモードの慣習にしたがってほしい。Major Mode Conventionsを参照のこと。
• マイナーモードを定義する際にはマイナーモードの慣習にしたがってほしい。Minor Mode Conventionsを参照のこと。
• ある関数の目的が特定の条件の真偽を告げることであるなら、(述語である“predicate”を意味する) ‘p’で終わる名前を与えること。その名前が1単語なら単に‘p’、複数単語なら‘-p’を追加する。例はframepやframe-live-p。
• ある変数の目的が単一の関数の格納にあるなら、‘-function’で終わる名前を与えること。ある変数の目的が関数のリストの格納にあるなら(たとえばその変数がフックなら)、フックの命名規約にしたがってほしい。Hooksを参照のこと。
• そのファイルをロードすることによりフックに関数が追加されるなら、feature-unload-functionという関数を定義すること。ここでfeatureはパッケージが提供する機能の名前であり、そのような変更をアンドゥするためのフックにする。そのファイルのアンロードにunload-featureを使用することにより、この関数が実行されるようになる。Unloadingを参照のこと。
• Emacsのプリミティブにエイリアスを定義するのは悪いアイデアである。かわりに通常は標準の名前を使用すること。エイリアスが有用になるかもしれないケースは後方互換性や可搬性を向上させる場合である。
• パッケージで別のバージョンのEmacsにたいする互換性のためにエイリアスや新たな関数の定義が必要なら、別のバージョンにあるそのままの名前ではなくパッケージのプレフィクスを名前に付加すること。以下はそのような互換性問題を多く提供するGnusでの例。

  (defalias 'gnus-point-at-bol
    (if (fboundp 'point-at-bol)
        'point-at-bol
      'line-beginning-position))
  

• Emacsのプリミティブの再定義やadviseは悪いアイデアである。これは特定のプログラムには正しいことを行うが結果として他のプロラムが破壊されるかもしれない。
• 同様にあるLispパッケージで別のLispパッケージ内の関数にadviseするのも悪いアイデアである。
• ライブラリやパッケージでのeval-after-loadとwith-eval-after-loadの使用を避けること(Hooks for Loadingを参照)。この機能は個人的なカスタマイズを意図している。Lispプログラム内でこれを使用すると別のLisp内ではそれが見えず、その挙動を変更するために不明瞭になる。これは別のパッケージ内の関数へのadviseと同様にデバッグの障害になる。
• Emacsの標準的な関数やライブラリープログラムの何かをファイルが置換するなら、そのファイル冒頭の主要コメントでどの関数が置換されるか、置換によりオリジナルと挙動がどのように異なるかを告げること。
• 関数や変数を定義するコンストラクターは関数ではなくマクロにして名前は‘define-’で始まること。そのマクロは定義される名前を1つ目の引数で受け取ること。これは自動的に定義を探す種々のツールの助けとなる。マクロ自身の中でその名前を構築するのは、それらのツールを混乱させるので避けること。
• 別のいくつかのシステムでは‘*’が先頭や終端にある変数名を選択する慣習がある。Emacs Lispではその慣習を使用しないので、あなたのプログラム内でそれを使用しないでほしい(Emacsでは特別な目的をもつバッファーだけにそのような名前を使用する)。すべてのライブラリーが同じ慣習を使用するなら人はEmacsがより整合性があることを見い出すだろう。
• Emacs LispソースファイルのデフォルトのファイルコーディングシステムはUTFである(Text Representationsを参照)。あなたのプログラムがUTF-8以外の文字を含むような稀なケースでは、ソースファイル内の‘-*-’行かローカル変数リスト内で適切なコーディングシステムを指定すること。Local Variables in Files in The GNU Emacs Manualを参照のこと。
• デフォルトのインデントパラメーターでファイルをインデントすること。
• 自分で行に閉カッコを配置するのを習慣としてはならない。Lispプログラマーはこれに当惑させられる。
• コピーを配布する場合は著作権表示と複製許可表示を配置してほしい。Library Headersを参照のこと。