| blob | cbf7c4ae155a3e6f07abdfc58e1e42ea407b827b |
1 *develop.txt* For Vim バージョン 7.1. Last change: 2007 May 11
4 VIM REFERENCE MANUAL by Bram Moolenaar
7 Vimの開発 *development*
9 この文書は、Vimの更なる開発に参加しようという人にとって重要である。
11 1. 設計上の目標 |design-goals|
12 2. コーディングスタイル |coding-style|
13 3. 決定事項 |design-decisions|
14 4. 想定していること |design-assumptions|
16 ソースコードの概要については"src"ディレクトリのREADME.txtを見てください。
18 Vimはオープンソースソフトウェアです。誰でもVimの開発に協力できます。パッチを送
19 る時はなるべく"context diff"形式("diff -c"で作る)でお願いします。
20 http://www.vim.org/tips/tip.php?tip_id=618 も見てください。
22 ==============================================================================
23 1. 設計上の目標 *design-goals*
25 重要度の順に従って書かれている(大雑把であるが)。
27 かなりの項目が矛盾していることを注意しておく。これは故意である。それらの
28 間で、バランスを取っていかねばならない。
31 VIM IS... VI COMPATIBLE *design-compatible*
33 なにより、VimはViの気軽な置き換えとして使うことができるべきである。ユーザ
34 が望むなら、Vimを、オリジナルのViとの区別がほとんど付かない互換モードで使う
35 ことができる。
37 例外:
38 - 明白なViのバグをVimに再現しない。
39 - Viには異なるバージョンが存在する。私はバージョン3.7(6/7/85)を参考として
40 使っている。しかし、他のバージョンのサポートも可能な限り取り込まれる。
41 POSIXにおけるViのパートは、決定的な資料とは考えない。
42 - Vimは新しいコマンドを持つため、Viにないコマンドを入力しても機能してしまう
43 場合がある。
44 - VimはViの持っていない多くの特徴を持つ。VimからViへ戻ることは問題を引き起こ
45 すが、これは避けられないことである。
46 - いくつかの事柄はめったに使われた例がない(オープンモード、クラッシュ時の
47 e-mailの送信、など)。これらは、誰かが何らかの理由でそれを入れるべきだと考
48 え、さらにその機能が働き過ぎない場合に限って取り入れられる。
49 - いくつかの項目に関しては、Vi互換を保るべきかどうか、議論の余地がある。これ
50 らに関しては、オプションフラグが作られるだろう。
53 VIM IS... IMPROVED *design-improved*
55 Vimの改良点は、それをよりよいViにすべきであって、まったく違ったエディタに
56 してしまってはならない。拡張は"Viの精神"に従って行われる。
57 - 可能な限りキーボードを使う。マウスは私たちの持たぬ第３の手を必要とする。
58 多くの端末はマウスを備えていない。
59 - それでもマウスを使うようであれば、キーボードに切り替える必要をなくす。
60 マウスとキーボードの操作の混在を避けよ。
61 - コマンドとオプションを矛盾なく追加せよ。でなければ、それらを見つけ出し、思い
62 出すのに、人々は苦労を強いられるだろう。後々、さらにコマンドやオプションが
63 追加されることを忘れてはならない。
64 - 特性は、人々が知らなければ役に立たない。目立たない特性は追加しない、あるいは、
65 少なくともその特性が存在するというヒントをドキュメントに追加すること。
66 - CTRLや他の修飾子の使用は最小限に留めよ、これらはタイプしにくい。
67 - 多くの初心者、不慣れなVimユーザがいる。Vimを使いはじめること、そしてより多く
68 を学んでいくことが、簡単にできるようにせよ。
69 - 特性は限りなく追加できる。新しく追加される特性は、(1)ユーザが求めていること、
70 (2)実装にどれほどの労力が必要か、そして(3)誰かが実際に実装している、といった
71 ことに基づいて選択される。
74 VIM IS... MULTI PLATFORM *design-multi-platform*
76 Vimは、可能な限り、多くのプラットホーム上の多くのユーザの助けでありたい。
77 - 多くの種類の端末をサポートする。最低限の要求は、カーソルの配置機能と画面の
78 クリアである。コマンドはたいていのキーボードが持つキーのみを使う。マッピン
79 グには、キーボード上の全てのキーを使うことができる。
80 - 多くのプラットホームをサポートする。必要条件は、誰かがそのプラットホーム上で
81 Vimの開発をしたいと考えること、それによってコードに混乱をきたさないこと、で
82 ある。
83 - 多くのコンパイラとライブラリをサポートする。全ての人が、他のコンパイラや
84 GUIライブラリをインストールできるわけではないからである。
85 - 人々は、あるプラットホームから別のプラットホームへ、そしてGUIから端末バー
86 ジョンへ移行する。特性は全てのバージョン、あるいは、少なくとも理に叶った労力
87 でできる限りのバージョンで、提供されるべきである。ユーザが能率的に仕事を仕上
88 げるために、プラットホームを切り替えねばならないような事態は避けたい。
89 - いくつかのプラットホームでは実現できない、または、ただひとつのプラットホーム
90 でしか実現できないような特性も、実装できないというわけではない。[これは前項
91 と故意に矛盾するものであり、両者の間でバランスが取られる。]
94 VIM IS... WELL DOCUMENTED *design-documented*
96 - 文書化されていない特性は、役に立たない。新しい特性を含んだパッチには、必ず
97 ドキュメントが含まれているべきである。
98 - ドキュメントは、わかりやすく、理解できるものであるべきだ。例を使うことが推
99 奨される。
100 - 文章を不必要に長くしてはならない。短い文章は、その項目を見つけやすくする。
103 VIM IS... HIGH SPEED AND SMALL IN SIZE *design-speed-size*
105 Vimを使うことで、システムリソースに大打撃を与えてはならない。Vimを小さく、
106 速く保つこと。
107 - コンピュータは年毎により速く、大容量になっている。Vimも成長しうるが、コン
108 ピュータの成長速度より速くなってはならない。Vimを古いシステム上でも使える
109 よう保つ必要がある。
110 - 多くのユーザは、Vimを頻繁にシェルから立ち上げる。起動は短時間でなくてはなら
111 ない。
112 - コマンドは能率的に働く必要がある。コマンドが消費する時間は、可能な限り短く
113 あるべきだ。役に立つコマンドなら、多少時間がかかってもよい。
114 - Vimを、遅い接続を通して使う人がいることを忘れてはならない。通信にかかるオー
115 バーヘッドは最小にすること。
116 - サイズがかなり大きく、多くの人によって使われるわけではない項目は、無効化で
117 きる特性とすべきである。
118 - Vimは、他のいろいろな構成要素の中にある、ひとつのコンポーネントである。巨大
119 なアプリケーションに変えてはならない、むしろ他のプログラムとよく協調するよう
120 にせよ。
123 VIM IS... MAINTAINABLE *design-maintain*
125 - ソースコードは乱雑になってはならない。そして、信頼できるものでなくてはな
126 らない。
127 - 読みやすくするため、すべてのファイルで同じレイアウトを取ること
128 |coding-style|。
129 - 役に立つコメントをいれること！関数名と引数名を引用しても役に立たない。それ
130 が何のためにあるのか説明すること。
131 - プラットホーム独立のコードに多くの変更を加える必要をなくし、他のプラットホ
132 ームへの移植を簡単にできるようにすること。
133 - オブジェクト指向の精神を使う: データとコードを同じ場所に。コードの他の部分
134 に関する知識は最小で済むように。
137 VIM IS... FLEXIBLE *design-flexible*
139 Vimは、そのユーザに特定の作業パターンを強いるよりは、ユーザの好むスタイルでの
140 作業を支援すべきである。これは大きなインパクトをもつ項目(例えば、'compatible'
141 オプション)や、その他の詳細によって実現される。デフォルトは、多くのユーザが
142 そのままのVimを楽しんで使えるように、慎重に選ばれている。コマンドとオプション
143 は、Vimをユーザの希望と環境に調整するために使われる。
146 VIM IS... NOT *design-not*
148 - Vimはシェルでも、オペレーティングシステムでもない。Vimの中でシェルを走らせた
149 り、デバッガを制御したりできるようにはならない。Vimは、もっと違った方法で機
150 能するものである: シェルやIDEの１つのコンポーネントとして使いなさい。
151 これを皮肉をもって言うならば: "Emacsとは違い、Vimは流し台以外の全てのものを
152 取り込もうとはしない、だが、VimでEmacsをきれいにすることはできるという ;-)"
153 A satirical way to say this: "Unlike Emacs, Vim does not attempt to include
154 everything but the kitchen sink, but some people say that you can clean one
155 with it. ;-)"
156 Vim と gdb を連携させる方法については次を参照:
157 http://www.agide.org と http://clewn.sf.net.
158 - Vimは、全てのプラットホームに渡って調和を欠くという代償を払って、見栄えをよ
159 くしようとする装飾的なGUIエディタではない。しかし、機能的なGUI特性は歓迎さ
160 れる。
162 ==============================================================================
163 2. コーディングスタイル *coding-style*
165 Vimのソースコードに変更を加える際、守るべきルールがある。ソースを読めるもの、
166 保守できるものとして保つため、これらのルールに従って欲しい。
168 このリストは完全ではない。より多くの例は、ソースコードを見て欲しい。
171 MAKING CHANGES *style-changes*
173 コードに変更を加える基本的なステップは:
174 1. ドキュメントを調整する。最初にこれをやることで、あなたの行う変更がユーザに
175 与える影響について、おおまかな印象をもつことができる。
176 2. ソースコードに変更を加える。
177 3. 変更がリストされた項目に影響を与えていないか、../doc/todo.txtをチェックす
178 る。
179 4. 無修正のコードとドキュメントに対するパッチを、"diff -c"によって得る。
180 5. 変更に関する注意書きを作り、パッチに含める。
183 USE OF COMMON FUNCTIONS *style-functions*
185 よく使われる関数のうち、特別なVimバージョンを持つものがある。これらは理由あっ
186 て導入されたものなので、常にVimバージョンを使うように意識すること。
188 NORMAL NAME VIM NAME DIFFERENCE OF VIM VERSION
189 free() vim_free() NULLの解放をチェックする
190 malloc() alloc() アウトオブメモリーの状況をチェックする
191 malloc() lalloc() alloc()に似ているが、長い引数を持つ
192 strcpy() STRCPY() char_u *引数を、(char *)へキャストする
193 strchr() vim_strchr() スペシャルキャラクタを受け入れる
194 strrchr() vim_strrchr() スペシャルキャラクタを受け入れる
195 isspace() vim_isspace() 128以上のキャラクタを扱うことができる
196 iswhite() vim_iswhite() Tabとスペースに対してのみTRUE
197 memcpy() mch_memmove() オーバーラップしたコピーを扱う
198 bcopy() mch_memmove() オーバーラップしたコピーを扱う
199 memset() vim_memset() 全てのシステムで一定である
202 NAMES *style-names*
204 関数の名前に31文字より長い名前は使えません。(VMSのために）
206 "delete"という名前の変数を使わないでください。C++で問題となります。
208 Vimができる限り多くのシステム上で走るという必要上、システムによってすでに定義
209 されている名前を使うことは避けねばならない。これは、問題となることが知られて
210 いる名前のリストである。名前はregexpパターンとして与えられている。
212 is.*() POSIX, ctype.h
213 to.*() POSIX, ctype.h
215 d_.* POSIX, dirent.h
216 l_.* POSIX, fcntl.h
217 gr_.* POSIX, grp.h
218 pw_.* POSIX, pwd.h
219 sa_.* POSIX, signal.h
220 mem.* POSIX, string.h
221 str.* POSIX, string.h
222 wcs.* POSIX, string.h
223 st_.* POSIX, stat.h
224 tms_.* POSIX, times.h
225 tm_.* POSIX, time.h
226 c_.* POSIX, termios.h
227 MAX.* POSIX, limits.h
228 __.* POSIX, system
229 _[A-Z].* POSIX, system
230 E[A-Z0-9]* POSIX, errno.h
232 .*_t POSIX, for typedefs, *_Tを使ってください。
234 wait types.hとコンフリクトするため、関数の引数として使わない
235 index グローバル宣言を覆い隠す
236 time グローバル宣言を覆い隠す
237 new C++の予約語
238 try Borland C++は、これを変数として使うことを好まない
240 basename() GNU 文字列関数(GNU string function)
241 dirname() GNU 文字列関数(GNU string function)
242 get_env_value() Linux システム関数
245 VARIOUS *style-various*
247 型の定義に使う名前は最後を"_T"にします: >
248 typedef int some_T;
249 マクロ定義はすべて大文字にします: >
250 #define SOME_THING
251 機能に関する定義は"FEAT_"で始めます: >
252 #define FEAT_FOO
254 '\"'を使わない、あるコンパイラはこれを扱えない。'"'はうまく機能する。
256 次を使ってはならない:
257 #if HAVE_SOME
258 あるコンパイラはこれを扱えず、"HAVE_SAME"が定義されていないと訴える。
259 次を使う
260 #ifdef HAVE_SOME
261 または
262 #if defined(HAVE_SOME)
265 STYLE *style-examples*
267 一般的なルール: １行に１つのステートメント。
269 間違い: if (cond) a = 1;
271 OK: if (cond)
272 a = 1;
274 間違い: while (cond);
276 OK: while (cond)
277 ;
279 間違い: do a = 1; while (cond);
281 OK: do
282 a = 1;
283 while (cond);
286 関数は次のようにして始める:
288 間違い: int function_name(int arg1, int arg2)
290 OK: /*
291 * Explanation of what this function is used for.
292 * この関数が何に使われるかの説明。
293 *
294 * Return value explanation.
295 * 戻り値の説明。
296 */
297 int
298 function_name(arg1, arg2)
299 int arg1; /* short comment about arg1 */
300 int arg2; /* short comment about arg2 */
301 {
302 int local; /* comment about local */
304 local = arg1 * arg2;
306 注意: ANSIスタイルの関数宣言を使わないこと。いまだそれをサポートしていないコ
307 ンパイラを使わねばならない人が、少ないながらいるからである。
310 SPACES AND PUNCTUATION *style-spaces*
312 関数名とブラケットの間にスペースを入れないこと:
314 間違い: func (arg);
315 OK: func(arg);
317 if、while、switchなどの後には、スペースを入れること。
319 間違い: if(arg) for(;;)
320 OK: if (arg) for (;;)
322 カンマ、セミコロンの後にはスペースを入れること:
324 間違い: func(arg1,arg2); for (i = 0;i < 2;++i)
325 OK: func(arg1, arg2); for (i = 0; i < 2; ++i)
327 '='、'+'、'/'などの前と後には、スペースを入れること。
329 間違い: var=a*5;
330 OK: var = a * 5;
332 一般的なこと: コードの行をグループ分けするために、空行を使う。行グループのす
333 ぐ上にコメントを入れる。こうすることによって、何が行われるのかをより簡単に知
334 ることができる。
336 OK: /* Prepare for building the table. */
337 /* テーブルの作成の準備 */
338 get_first_item();
339 table_idx = 0;
341 /* Build the table */
342 /* テーブルの作成 */
343 while (has_item())
344 table[table_idx++] = next_item();
346 /* Finish up. */
347 /* 仕上げ */
348 cleanup_items();
349 generate_hash(table);
351 ==============================================================================
352 3. 決定事項 *design-decisions*
354 折畳(folding)
356 同じバッファにいくつもの折畳状態を設定可能にする。例えば、あるウインドウに関
357 数を折畳んだ状態で表示し、他のウインドウで関数の中身を表示するなど。
359 折畳はテキストを表示する方法である。テキストを変更すべきではない。したがってバッ
360 ファ内のテキストをウインドウに表示する際のフィルタとして実行される。
363 ウインドウの名前
365 "ウインドウ"という単語は一般にいくつかの意味で使われている。スクリーン上のウ
366 インドウ、xtermのウインドウ、Vimのバッファを表示するウインドウなど。
368 混乱を避けるため、時にウインドウと呼ばれる他の物には別の名前が付けられてい
369 る。ここに関連する物の概観を示す。
371 スクリーン(screen) ディスプレイ全体。GUIでは例えば1024x768ピクセルの画
372 面。Vimシェルはスクリーン全体を使うことも一部を使う
373 こともできる。
375 シェル(shell) Vimアプリケーション。スクリーン全体(例えばコンソール
376 で実行した時)、あるいはその一部(xtermやGUI)。
378 ウインドウ(window) バッファの表示画面。Vimは複数のウインドウを持つこと
379 ができる。ウインドウはコマンドラインやメニューバー、
380 ツールバーなどといっしょに表示される。これらはシェル
381 に納まる。
383 スペルチェック *develop-spell*
385 Vim にスペルチェックを追加することになったとき、利用可能なスペルチェックのライ
386 ブラリやプログラムについて調査が行われた。その結果は残念なことに、Vim 内でスペ
387 ルチェックエンジンとして使えるものはないとわかった。これには様々な理由がある:
389 - マルチバイトエンコーディングをサポートしていない。1つのファイル内で複数の言
390 語を使えるようにするために、少なくとも UTF-8 はサポートしていなければならな
391 い。
392 オンザフライな変換は常に可能とは限らない(iconv に対応している必要がある)。
393 - プログラムとライブラリに対して: それらをそのまま(as-is)使うには、Vim と別個
394 にインストールしなければならない。これはたいてい不可能ではないが、難点である。
395 - パフォーマンス: いくつかのテストによると、スペルチェックを構文強調のようにオ
396 ンザフライで(再描画中に)行うことは可能であった。しかし他のコードで使われたメ
397 カニズムはもっと遅かった。例えば、Myspell はハッシュテーブルを使用する。ほと
398 んどのスペルチェッカが使用している接辞圧縮を使うと遅くなった。
399 - aspell のような外部プログラムを使うには、通信メカニズムを用意しなければなら
400 ない。これをポータブルな方法で行うのは複雑過ぎる(Unix だけなら比較的簡単だが、
401 それでは十分ではない)。そしてパフォーマンスが問題になる(何回ものプロセス切替
402 が行われる)。
403 - "Etten-Leur" や "et al." など、単語でない単語のサポートを欠いている。そのた
404 めこれらの部分を OK とマークしなければならないが、そうすると信頼性が低下する。
405 - 地域や方言のサポートを欠いている。英語の単語をすべて受け付け、カナダ語でない
406 単語を別に扱うことが難しくなる。
407 - 頻度が低い単語のサポートを欠いている。正しいがめったに使われないたくさんの単
408 語が、よく使われる単語のスペルミスとみなされてしまう。
409 - スペル候補を作成するには速度はそれほど重要ではなく、他のプログラムやライブラ
410 リをインストールすることは許容できる。しかし、単語リストが異なるとスペル候補
411 が誤単語になってしまう。
414 スペル候補 *develop-spell-suggestions*
416 候補の作成には2つの基本的なメカニズムがある:
417 1. 誤った単語を少し変更して正しい単語とマッチするかチェックする。あるいは、正
418 しい単語全てに対し、それを少し変更して誤った単語とマッチするかチェックする。
419 変更とは、文字の削除・文字の挿入・2つの文字の交換などである。
420 2. 誤った単語と正しい単語のリストの両方に soundfolding (発音が近い単語を同じグ
421 ループとみなすこと) を行って、そこでマッチを見つける。1番目のメカニズムと同
422 様にいくつか変更をしてもよい。
424 最初のメカニズムはタイプミスを見つけるのにはよい。ハッシュテーブルの実験と、他
425 のスペルチェッカのソリューションを見ると、これにはtrie(ツリー構造の一種)が最適
426 であるとの結論になった。メモリ使用量の削減と、賢い変更を試みるということの両方
427 に面でである。例えば、文字を挿入するときは正しい単語につながる文字だけを試せば
428 よい。他の(ハッシュテーブルを使った)メカニズムは、単語のすべての位置で、ありう
429 るすべての文字を試さねばならない、また、ハッシュテーブルを使うには、単語の境界
430 が個別に認識されなければならないのに対し、trie はそれを要求しない。そのためメ
431 カニズムがより単純になる。
433 ある単語の発音は知っているがスペルを知らないという場合に soundfolding は有用で
434 ある。例えば、"dictionary"という単語を"daktonerie"と書いてしまうかもしれない。
435 これを最初の方法で訂正しようとすると変更回数が非常に多くなってしまい、正しいス
436 ペルを見つけるのは困難である。それに対し、これらの単語にsoundfoldingを行うと
437 "tktnr"と"tkxnry"になり、2文字しか違わない。
439 soundfoldの同値(音が似ている単語)により単語を見つけるには全てのsoundfolded
440 wordsのリストが必要である。どれが最良の方法かを探すための実験が行われた。案:
441 1. 修正候補を探すときに、その場でsound foldingを行う。つまり、正しい単語のtrie
442 をたどりながら、各単語をsoundfoldingし、それがスペルミスしている単語からど
443 れだけ異なるかをチェックする。これはメモリ効率の面でとても優れているが、時
444 間は長くかかる。英語の場合、高速なPCで2秒ほどかかる。これは対話的な利用とし
445 て受け入れられる。しかしいくつかの言語(ドイツ語、カタルニャ語など)に対して
446 は10秒以上かかり、受け入れがたい。バッチ処理(自動訂正)に使うには全ての言語
447 で遅すぎる。
448 2. soundfoldされた単語に対してtrieを使い、soundfoldingなしのときとまったく同じ
449 ように検索できるようにする。そのためには、soundfoldされた各単語に対し、正し
450 い単語のリストを記憶しておく必要がある。そうすると照合がとても高速になるが、
451 1MB〜10MBのオーダーの大量のメモリを必要とする。ある言語の場合は元の単語のリ
452 ストよりも多くなる。
453 3. 2番目の案と同様だが、接辞圧縮を使い、soundfoldした基本単語だけを保存するこ
454 とによりメモリ消費量をへらす。これはAspellが採用している方法である。不利点
455 は、誤った単語をsoundfoldする前に接辞を取り除いておかねばならないことである。
456 そのため、単語の先頭・末尾における誤りに対しては対応できない。また、誤った
457 単語が正しい単語から大きく異なるときは遅くなる。
459 我々が採用したのは、2番目のメカニズムを使い、別ファイルを使う方法である。こう
460 することによって、十分なメモリを持っているユーザはとてもよい候補を得ることがで
461 きるし、メモリが不足しているユーザやスペルチェックだけで候補は出さなくてよいと
462 いうユーザはそれほどメモリを使わなくてすむ。
465 単語の頻度
467 候補をソートするにはどの単語が共通であるかを知ると役にたつ。理論的には単語の頻
468 度は単語とともに辞書の中に保持することができる。しかしそうすると単語につき回数
469 を保持しなければならない。これは単語ツリー圧縮を大いに劣化させる。また、全ての
470 言語に対して単語の頻度を保守するのは大変な作業である。
471 また、テキストに既に出てきている単語を優先するとよいだろう。このようにして特定
472 のテキスト内に表れる単語は候補の中で優先度が高くなる。
474 実装されたのは、表示中に単語を数えることである。ハッシュテーブルを使ってその単
475 語の回数を高速に検索する。回数は接辞ファイルでCOMMONアイテムにリストされている
476 単語から初期化される。そのため新規ファイルの編集を始めたときも機能する。
478 これは理想的ではない。Vimが長時間稼働しているほど回数は大きくなるためである。
479 しかし実用的には単語の回数を使わない場合に比べて注目に値するほどの改善である。
481 ==============================================================================
482 4. Assumptions *design-assumptions*
484 変数のサイズ:
485 char 8 bit signed
486 char_u 8 bit unsigned
487 int 32 or 64 bit signed (限定された機能については16ビットもありうる)
488 unsigned 32 or 64 bit unsigned (16ビットについてはintと同様)
489 long 32 or 64 bit signed, can hold a pointer
491 Note いくつかのコンパイラは長すぎる行は文字列をうまく扱えない。C89の標準規格で
492 は509文字までに制限されている。
494 vim:tw=78:ts=8:ft=help:norl: