次へ: コンパイル済みコードを高速にするためのヒント, 前へ: キーバインドの規約, 上へ: ヒントと規約   [目次][索引]

D.3 Emacsプログラミングのヒント ¶

これらの規約に従うことで、プログラム実行時にEmacsによりうまく馴染むようになります。

• プログラム内で next-line や previous-line は使用しないでください。ほとんどの場合、forward-line の方が便利であり、予測可能性と堅牢性にも優れています。テキスト行による移動 を参照してください。
• マークを設定する機能は、マークの設定がプログラムの意図した機能の一つである場合を除き、呼び出さないでください。マークはユーザーレベルの機能であるため、ユーザーの便宜のために値を渡す場合を除き、マークを変更するのは不適切です。マークを参照してください。

  特に、以下の関数は一切使用しないでください：

  • beginning-of-buffer, end-of-buffer
  • replace-string, replace-regexp
  • insert-file, insert-buffer

  インタラクティブユーザー向けのその他の機能は一切不要で、単にポイントを移動させたり、特定の文字列を置換したり、あるいはファイルやバッファの内容を挿入したりしたいだけであれば、これらの機能を1、2行のシンプルなLispコードで置き換えることができます。

• ベクトルを使う特別な理由がない限り、ベクトルではなくリストを使用してください。Lispにはベクトルよりもリストを操作するための機能が豊富に備わっており、通常はリストを扱う方が便利です。

  ベクトルは、要素の挿入や削除の必要がない場合（リストのみがそれを可能とする）、サイズが大きく、かつランダムな順序でアクセスされる（先頭から末尾に向かって検索しない）テーブルに適している。

• エコーエリアにメッセージを表示する推奨方法は、princではなくmessage関数を使用することです。エコーエリアを参照してください。
• エラー条件が発生した場合は、関数 error（または signal）を呼び出してください。関数 error は戻り値を返しません。エラーの通知方法を参照してください。

  エラーの報告に message、throw、sleep-for、または beep を使用しないでください。

• エラーメッセージは大文字で始まり、末尾にピリオドやその他の句読点を置いてはなりません。

  debug-on-error が nil である場合でも、エラーの発生箇所をユーザーに伝えることが有用な場合があります。このような場合には、エラーメッセージの先頭に小文字の Lisp シンボルを付加することができます。例えば、「Invalid input」というエラーメッセージを、「some-function: Invalid input」のように拡張することが可能です。

• ミニバッファで yes-or-no-p または y-or-n-p を用いて入力する質問は、大文字で始まり、‘?’ で終わる必要があります。
• ミニバッファのプロンプトでデフォルト値を指定する場合は、その値と単語 ‘default’ を括弧で囲んでください。以下のようになります：

  Enter the answer (default 42):
  

• interactive において、Lisp式を用いて引数のリストを生成する場合、region や position 引数に正しいデフォルト値を指定しようとしないでください。代わりに、それらの引数が指定されていない場合は nil とし、引数が nil であるときに関数本体でデフォルト値を計算するようにしてください。例えば、次のように記述します。

  (defun foo (pos)
    (interactive
     (list (if specified specified-pos)))
    (unless pos (setq pos default-pos))
    ...)
  

  これではなく：

  (defun foo (pos)
    (interactive
     (list (if specified specified-pos
               default-pos)))
    ...)
  

  これは、コマンドを再実行した際に、現在の状況に基づいてこれらのデフォルト値を再計算するためです。

  インタラクティブな仕様 ‘d’、‘m’、‘r’ を使用する場合、コマンドの繰り返し時に引数の値を再計算するための特別な仕組みが備わっているため、このような対策を講じる必要はありません。

• Many commands that take a long time to execute display a message that says something like ‘Operating...’ when they start, and change it to ‘Operating...done’ when they finish. Please keep the style of these messages uniform: no space around the ellipsis, and no period after ‘done’. See Reporting Operation Progress, for an easy way to generate such messages.
• 再帰的な編集は避けるようにしてください。代わりに、Rmailのeコマンドと同様の方法をとりましょう。つまり、元のローカルキーマップに戻るためのコマンドを定義した、新しいローカルキーマップを使用するのです。あるいは、単に別のバッファに切り替え、ユーザーが任意に戻れるようにしてください。再帰的編集を参照してください。