develop.txt For Vim バージョン 9.1. Last change: 2024 Nov 11
VIMリファレンスマニュアル by Bram Moolenaar
Vimの開発 development
この文書は、Vimの更なる開発に参加しようという人にとって重要である。
1. 設計上の目標 design-goals
2. コーディングスタイル coding-style
3. 決定事項 design-decisions
4. 想定していること design-assumptions
ソースコードの概要については "src" ディレクトリのREADME.txtを見てください。
Vimはオープンソースソフトウェアです。誰でもVimの開発に協力できます。パッチを送
る時はなるべく "unified diff" 形式 ("diff -u" で作る) でお願いします。
GitHub上でプルリクエストを作ることも可能ですが、必須ではありません。
http://vim.wikia.com/wiki/How_to_make_and_submit_a_patch も見てください。
==============================================================================
1. 設計上の目標 design-goals
重要度の順に従って書かれている(大雑把であるが)。
かなりの項目が矛盾していることを注意しておく。これは故意である。それらの間で、
バランスを取っていかねばならない。
Vimは... Vi互換である design-compatible
何より、VimはViの気軽な置き換えとして使うことができるべきである。ユーザーが望
むなら、Vimは、オリジナルのViとの区別がほとんど付かない互換モードで使うことが
できる。
例外:
- 明白なViのバグをVimに再現しない。
- Viには異なるバージョンが存在する。私はバージョン3.7(6/7/85)を参考として
使っている。しかし、他のバージョンのサポートも可能な限り取り込まれる。
POSIXにおけるViのパートは、決定的な資料とは考えない。
- Vimは新しいコマンドを持つため、Viにないコマンドを入力しても機能してしまう
場合がある。
- VimはViの持っていない多くの特徴を持つ。VimからViへ戻ることは問題を引き起こ
すが、これは避けられないことである。
- いくつかの事柄はめったに使われた例がない(オープンモード、クラッシュ時の
e-mailの送信、など)。これらは、誰かが何らかの理由でそれを入れるべきだと考
え、さらにその機能が働き過ぎない場合に限って取り入れられる。
- いくつかの項目に関しては、Vi互換を保つべきかどうか、議論の余地がある。これ
らに関しては、オプションフラグが作られるだろう。
Vimは... 改良されている design-improved
Vimの改良点は、それをよりよいViにすべきであって、まったく違ったエディタに
してしまってはならない。拡張は "Viの精神" に従って行われる。
- 可能な限りキーボードを使う。マウスは私たちの持たぬ第３の手を必要とする。
多くの端末はマウスを備えていない。
- それでもマウスを使うようであれば、キーボードに切り替える必要をなくす。
マウスとキーボードの操作の混在を避けよ。
- コマンドとオプションを矛盾なく追加せよ。でなければ、それらを見つけ出し、思い
出すのに、人々は苦労を強いられるだろう。後々、さらにコマンドやオプションが
追加されることを忘れてはならない。
- 特性は、人々が知らなければ役に立たない。目立たない特性は追加しない、あるいは、
少なくともその特性が存在するというヒントをドキュメントに追加すること。
- CTRLや他の修飾子の使用は最小限に留めよ、これらはタイプしにくい。
- 多くの初心者、不慣れなVimユーザーがいる。Vimを使いはじめること、そしてより多
くを学んでいくことが、簡単にできるようにせよ。
- 特性は限りなく追加できる。新しく追加される特性は、(1)ユーザーが求めているこ
と、(2)実装にどれほどの労力が必要か、そして(3)誰かが実際に実装している、と
いったことに基づいて選択される。
Vimは... マルチプラットフォーム design-multi-platform
Vimは、可能な限り、多くのプラットフォーム上の多くのユーザーの助けでありたい。
- 多くの種類の端末をサポートする。最低限の要求は、カーソルの配置機能と画面の
クリアである。コマンドはたいていのキーボードが持つキーのみを使う。マッピン
グには、キーボード上の全てのキーを使うことができる。
- 多くのプラットフォームをサポートする。必要条件は、誰かがそのプラットフォーム
上でVimの開発をしたいと考えること、それによってコードに混乱をきたさないこと、
である。
- 多くのコンパイラとライブラリをサポートする。全ての人が、他のコンパイラや
GUIライブラリをインストールできるわけではないからである。
- 人々は、あるプラットフォームから別のプラットフォームへ、そしてGUIから端末
バージョンへ移行する。特性は全てのバージョン、あるいは、少なくとも理に叶った
労力でできる限りのバージョンで、提供されるべきである。ユーザーが能率的に仕事
を仕上げるために、プラットフォームを切り替えねばならないような事態は避けたい。
- いくつかのプラットフォームでは実現できない、または、ただひとつのプラット
フォームでしか実現できないような特性も、実装できないというわけではない。[こ
れは前項と故意に矛盾するものであり、両者の間でバランスが取られる。]
Vimは... 文書化されている design-documented
- 文書化されていない特性は、役に立たない。新しい特性を含んだパッチには、必ず
ドキュメントが含まれているべきである。
- ドキュメントは、わかりやすく、理解できるものであるべきだ。例を使うことが推
奨される。
- 文章を不必要に長くしてはならない。短い文章は、その項目を見つけやすくする。
Vimは... 高速で小さいサイズ design-speed-size
Vimを使うことで、システムリソースに大打撃を与えてはならない。Vimを小さく、
速く保つこと。
- コンピュータは年毎により速く、大容量になっている。Vimも成長しうるが、コン
ピュータの成長速度より速くなってはならない。Vimを古いシステム上でも使える
よう保つ必要がある。
- 多くのユーザーは、Vimを頻繁にシェルから立ち上げる。起動は短時間でなくてはな
らない。
- コマンドは能率的に働く必要がある。コマンドが消費する時間は、可能な限り短く
あるべきだ。役に立つコマンドなら、多少時間がかかってもよい。
- Vimを、遅い接続を通して使う人がいることを忘れてはならない。通信にかかるオー
バーヘッドは最小にすること。
- サイズがかなり大きく、多くの人によって使われるわけではない項目は、無効化で
きる特性とすべきである。
- Vimは、他のいろいろな構成要素の中にある、ひとつのコンポーネントである。巨大
なアプリケーションに変えてはならない、むしろ他のプログラムとよく協調するよう
にせよ。
Vimは... 保守性が高い design-maintain
- ソースコードは乱雑になってはならない。そして、信頼できるものでなくてはな
らない。
- 読みやすくするため、すべてのファイルで同じレイアウトを取ること
coding-style。
- 役に立つコメントをいれること！関数名と引数名を引用しても役に立たない。それ
が何のためにあるのか説明すること。
- プラットフォーム独立のコードに多くの変更を加える必要をなくし、他のプラット
フォームへの移植を簡単にできるようにすること。
- オブジェクト指向の精神を使う: データとコードを同じ場所に。コードの他の部分
に関する知識は最小で済むように。
Vimは... 柔軟である design-flexible
Vimは、そのユーザーに特定の作業パターンを強いるよりは、ユーザーの好むスタイル
での作業を支援すべきである。これは大きなインパクトをもつ項目(例えば、
'compatible' オプション)や、その他の詳細によって実現される。デフォルトは、多く
のユーザーがそのままのVimを楽しんで使えるように、慎重に選ばれている。コマンド
とオプションは、Vimをユーザーの希望と環境に調整するために使われる。
Vimは... こうではない design-not
- Vim はシェルでもオペレーティングシステムでもない。Vim はターミナルウィンドウ
を提供し、その中でシェルやデバッガを走らせることができる。例えば、ssh 接続越
しにこれをすることが可能だ。しかし、このようなものにテキストエディタが必要な
いなら守備範囲外だ (代わりに screen や tmux のようなものを使おう)。
風刺を込めて曰く: "Vim は Emacs のように流し台以外ならなんでもかんでも取り込
んでしまうようなことはしないが、Vim で流し台を洗うことはできるぞ。 ;-)"
Vim と gdb を連携させる方法については terminal-debugger を参照。他の(古い)
ツールは http://www.agide.org (リンク切れのようだ) と http://clewn.sf.net で
見つけることができる。
- Vimは、全てのプラットフォームに渡って調和を欠くという代償を払って、見栄えを
よくしようとする装飾的なGUIエディタではない。しかし、機能的なGUI特性は歓迎さ
れる。
==============================================================================
2. コーディングスタイル coding-style
Vimのソースコードに変更を加える際、守るべきルールがある。ソースを読めるもの、
保守できるものとして保つため、これらのルールに従って欲しい。
このリストは完全ではない。より多くの例は、ソースコードを見て欲しい。
コードリポジトリには editorconfig ファイルが含まれており、配布されている
editorconfig プラグイン editorconfig-install と一緒に使用し、推奨スタイルに
従うようにすることができる。
変更する style-changes
コードに変更を加える基本的なステップは:
1. GitHub からコードを取得する。これによりあなたが変更したコードをメインのコー
ドベースに同期するのがより簡単になる (あなたの変更がメインのコードベースに
含まれるようになるまで少しかかるかもしれない) 。
2. ドキュメントを調整する。最初にこれをやることで、あなたの行う変更がユーザー
に与える影響について、おおまかな印象をもつことができる。
3. ソースコードに変更を加える。
4. 変更がリストされた項目に影響を与えていないか、../doc/todo.txtをチェックす
る。
5. 新しい動作を検証し、将来的に問題が発生しないことを確認するために、
src/testdir にテストを追加する。
6. "git diff" でパッチを作成する。
7. 変更点について付記し、できれば問題と解決策についても記載すること。説明と差
分を添えて、vim-dev メーリングリストにメールを送信する。
些細な変更でない場合は、必ず github でプルリクエストを作成すること。これによ
り、テストスイートがトリガーされる。
Cコンパイラ style-compiler ANSI-C C89 C99
サポートされている最小の C コンパイラのバージョンは C89 (ANSI C とも呼ばれてい
る) である。C99 のような後継の標準規格はあまり普及していない、もしくは少なくと
も 100% サポートされているわけではない。したがって、C99 機能の一部のみを使用
し、一部を明示的に禁止する (これは時間の経過とともに徐々に調整される)。
使用してはいけない機能
これらの C99 の機能は、コンパイラのサポートが不十分なため使用してはいけない:
- 可変長配列 (C11 でもこれはオプショナルな機能である)。
- C99 の _Bool 型と _Complex 型。
- "inline" (ほとんど必要ない、コンパイラに最適化させよう。)
- フレキシブル配列メンバ: HP-UX C コンパイラはサポートしていない。(John
Marriott)
コメント style-comments
関数本体内に複数行のコメントを入れないようにすること。関数が非常に複雑で、一部
を個別にコメントする必要がある場合は、関数の構造を再検討する必要がある。
ファイルヘッダーと関数の説明には以下を使用:
その他すべてには以下を使用:
インデント style-indentation
コードのインデントには 4 つのスペースを使用する。Vim を使用してソースを編集し
ている場合は、modeline があるため何もする必要はない。
他のエディタの場合は、リポジトリのルートに .editorconfig が提供される。
宣言 style-declarations
可能であれば、ガード内で for ループ変数を宣言する:
OK:
間違い:
常にデフォルト値を持つ変数を宣言する:
OK:
間違い:
括弧 style-braces
すべての波括弧は改行しなければならない:
OK:
間違い:
OK:
間違い:
ブロックがコメントを含めて 1 行の場合は、波括弧は省略できる。
OK:
間違い:
if/else の一方のブロックに波括弧がある場合は、もう一方のブロックにも波括弧
が必要である。
OK:
間違い:
OK:
間違い:
型 style-types
記述的な型を使用すること。それらのリストは src/structs.h ファイル内、またはお
そらく作業中のファイルの typedef 内にある。
Note すべてのカスタム型には「_T」という接尾辞が付けられることに注意
OK:
間違い:
空白と句読法 style-spaces
関数名と括弧の間に空白はない:
OK: func(arg);
間違い: func (arg);
if, while, switch 等の後には空白を入れること。
OK: if (arg) for (;;)
間違い: if(arg) for(;;)
コンマまたはセミコロンの後に空白を入れる:
OK: func(arg1, arg2); for (i = 0; i < 2; ++i)
間違い: func(arg1,arg2); for (i = 0;i < 2;++i)
'=', '+', '/' 等の前後に空白を入れる。
間違い: var=a*5;
OK: var = a * 5;
似たような動作をグループ化するには、空行を使う。
OK:
間違い:
関数 style-functions
関数宣言は、戻り値の型を別のインデントされた行に記述して使用する:
OK:
間違い:
関数パラメータに意味のある名前を付ける。
共通関数を使う style-common-functions
よく使われる関数のうち、特別なVimバージョンを持つものがある。これらは理由あっ
て導入されたものなので、常にVimバージョンを使うように意識すること。
NORMAL NAME VIM NAME DIFFERENCE OF VIM VERSION
free() vim_free() NULLの解放をチェックする
malloc() alloc() アウトオブメモリの状況をチェックする
malloc() lalloc() alloc()に似ているが、long型の引数を持つ
strcpy() STRCPY() char_u *引数を、(char *)へキャストする
strchr() vim_strchr() スペシャルキャラクタを受け入れる
strrchr() vim_strrchr() スペシャルキャラクタを受け入れる
isspace() vim_isspace() 128以上のキャラクタを扱うことができる
iswhite() vim_iswhite() Tabとスペースに対してのみTRUE
memcpy() mch_memmove() オーバーラップしたコピーを扱う
bcopy() mch_memmove() オーバーラップしたコピーを扱う
memset() vim_memset() 全てのシステムで一定である
名前 style-names
関数の名前に31文字より長い名前は使えない。(VMSのために)
"delete" や "this" という名前の変数を使わないこと。C++で問題となる。
Vimができる限り多くのシステム上で走るという必要上、システムによってすでに定義
されている名前を使うことは避けねばならない。これは、問題となることが知られて
いる名前のリストである。名前はregexpパターンとして与えられている。
is.*() POSIX, ctype.h
to.*() POSIX, ctype.h
d_.* POSIX, dirent.h
l_.* POSIX, fcntl.h
gr_.* POSIX, grp.h
pw_.* POSIX, pwd.h
sa_.* POSIX, signal.h
mem.* POSIX, string.h
str.* POSIX, string.h
wcs.* POSIX, string.h
st_.* POSIX, stat.h
tms_.* POSIX, times.h
tm_.* POSIX, time.h
c_.* POSIX, termios.h
MAX.* POSIX, limits.h
__.* POSIX, system
_[A-Z].* POSIX, system
E[A-Z0-9]* POSIX, errno.h
.*_t POSIX, for typedefs, *_T を使うこと。
wait types.hとコンフリクトするため、関数の引数として使わない
index グローバル宣言を覆い隠す
time グローバル宣言を覆い隠す
new C++の予約語
clear Mac curses.h
echo Mac curses.h
instr Mac curses.h
meta Mac curses.h
newwin Mac curses.h
nl Mac curses.h
overwrite Mac curses.h
refresh Mac curses.h
scroll Mac curses.h
typeahead Mac curses.h
basename() GNU 文字列関数(GNU string function)
dirname() GNU 文字列関数(GNU string function)
get_env_value() Linux システム関数
その他 style-various
マクロ定義はすべて大文字にする:
機能に関する定義は "FEAT_" で始める:
'\"' を使わない、あるコンパイラはこれを扱えない。'"' はうまく機能する。
以下を使ってはならない:
あるコンパイラはこれを扱えず、"HAVE_SOME" が定義されていないと訴える。
以下を使う
または
スタイル style-examples
１行に１つのステートメント。
間違い: if (cond) a = 1;
OK: if (cond)
a = 1;
間違い: while (cond);
OK: while (cond)
;
間違い: do a = 1; while (cond);
OK: do
a = 1;
while (cond);
==============================================================================
3. 決定事項 design-decisions
折り畳み(folding)
同じバッファにいくつもの折り畳み状態を設定可能にする。例えば、あるウィンドウに
関数を折り畳んだ状態で表示し、他のウィンドウで関数の中身を表示するなど。
折り畳みはテキストを表示する方法である。テキストを変更すべきではない。したがっ
てバッファ内のテキストをウィンドウに表示する際のフィルタとして実行される。
ウィンドウの名前
"ウィンドウ" という単語は一般にいくつかの意味で使われている。スクリーン上のウィ
ンドウ、xtermのウィンドウ、Vimのバッファを表示するウィンドウなど。
混乱を避けるため、時にウィンドウと呼ばれる他の物には別の名前が付けられている。
ここに関連する物の概観を示す。
スクリーン(screen) ディスプレイ全体。GUIでは例えば1024x768ピクセルの画
面。Vimシェルはスクリーン全体を使うことも一部を使う
こともできる。
シェル(shell) Vimアプリケーション。スクリーン全体(例えばコンソール
で実行した時)、あるいはその一部(xtermやGUI)。
ウィンドウ(window) バッファの表示画面。Vimは複数のウィンドウを持つこと
ができる。ウィンドウはコマンドラインやメニューバー、
ツールバーなどといっしょに表示される。これらはシェル
に納まる。
スペルチェック develop-spell
Vim にスペルチェックを追加することになったとき、利用可能なスペルチェックのライ
ブラリやプログラムについて調査が行われた。その結果は残念なことに、Vim 内でスペ
ルチェックエンジンとして使えるものはないとわかった。これには様々な理由がある:
- マルチバイトエンコーディングをサポートしていない。1つのファイル内で複数の言
語を使えるようにするために、少なくとも UTF-8 はサポートしていなければならな
い。
オンザフライな変換は常に可能とは限らない(iconv に対応している必要がある)。
- プログラムとライブラリに対して: それらをそのまま(as-is)使うには、Vim と別個
にインストールしなければならない。これはたいてい不可能ではないが、難点である。
- パフォーマンス: いくつかのテストによると、スペルチェックを構文強調のようにオ
ンザフライで(再描画中に)行うことは可能であった。しかし他のコードで使われたメ
カニズムはもっと遅かった。例えば、Myspell はハッシュテーブルを使用する。ほと
んどのスペルチェッカが使用している接辞圧縮を使うと遅くなった。
- aspell のような外部プログラムを使うには、通信メカニズムを用意しなければなら
ない。これをポータブルな方法で行うのは複雑過ぎる(Unix だけなら比較的簡単だが、
それでは十分ではない)。そしてパフォーマンスが問題になる(何回ものプロセス切替
が行われる)。
- "Etten-Leur" や "et al." など、単語でない単語のサポートを欠いている。そのた
めこれらの部分を OK とマークしなければならないが、そうすると信頼性が低下する。
- 地域や方言のサポートを欠いている。英語の単語をすべて受け付け、カナダ語でない
単語を別に扱うことが難しくなる。
- 頻度が低い単語のサポートを欠いている。正しいがめったに使われないたくさんの単
語が、よく使われる単語のスペルミスとみなされてしまう。
- スペル候補を作成するには速度はそれほど重要ではなく、他のプログラムやライブラ
リをインストールすることは許容できる。しかし、単語リストが異なるとスペル候補
が誤単語になってしまう。
スペル候補 develop-spell-suggestions
候補の作成には2つの基本的なメカニズムがある:
1. 誤った単語を少し変更して正しい単語とマッチするかチェックする。あるいは、正
しい単語全てに対し、それを少し変更して誤った単語とマッチするかチェックする。
変更とは、文字の削除・文字の挿入・2つの文字の交換などである。
2. 誤った単語と正しい単語のリストの両方に soundfolding (発音が近い単語を同じグ
ループとみなすこと) を行って、そこでマッチを見つける。1番目のメカニズムと同
様にいくつか変更をしてもよい。
最初のメカニズムはタイプミスを見つけるのにはよい。ハッシュテーブルの実験と、他
のスペルチェッカのソリューションを見ると、これにはtrie(ツリー構造の一種)が最適
であるとの結論になった。メモリ使用量の削減と、賢い変更を試みるということの両方
の面でである。例えば、文字を挿入するときは正しい単語につながる文字だけを試せば
よい。他の(ハッシュテーブルを使った)メカニズムは、単語のすべての位置で、ありう
るすべての文字を試さねばならない、また、ハッシュテーブルを使うには、単語の境界
が個別に認識されなければならないのに対し、trie はそれを要求しない。そのためメ
カニズムがより単純になる。
ある単語の発音は知っているがスペルを知らないという場合に soundfolding は有用で
ある。例えば、"dictionary" という単語を "daktonerie" と書いてしまうかもしれな
い。これを最初の方法で訂正しようとすると変更回数が非常に多くなってしまい、正し
いスペルを見つけるのは困難である。それに対し、これらの単語にsoundfoldingを行う
と "tktnr" と "tkxnry" になり、2文字しか違わない。
soundfoldの同値(音が似ている単語)により単語を見つけるには全てのsoundfolded
wordsのリストが必要である。どれが最良の方法かを探すための実験が行われた。案:
1. 修正候補を探すときに、その場でsound foldingを行う。つまり、正しい単語のtrie
をたどりながら、各単語をsoundfoldingし、それがスペルミスしている単語からど
れだけ異なるかをチェックする。これはメモリ効率の面でとても優れているが、時
間は長くかかる。英語の場合、高速なPCで2秒ほどかかる。これは対話的な利用とし
て受け入れられる。しかしいくつかの言語(ドイツ語、カタルニャ語など)に対して
は10秒以上かかり、受け入れがたい。バッチ処理(自動訂正)に使うには全ての言語
で遅すぎる。
2. soundfoldされた単語に対してtrieを使い、soundfoldingなしのときとまったく同じ
ように検索できるようにする。そのためには、soundfoldされた各単語に対し、正し
い単語のリストを記憶しておく必要がある。そうすると照合がとても高速になるが、
1MB〜10MBのオーダーの大量のメモリを必要とする。ある言語の場合は元の単語のリ
ストよりも多くなる。
3. 2番目の案と同様だが、接辞圧縮を使い、soundfoldした基本単語だけを保存するこ
とによりメモリ消費量を減らす。これはAspellが採用している方法である。不利点
は、誤った単語をsoundfoldする前に接辞を取り除いておかねばならないことである。
そのため、単語の先頭・末尾における誤りに対しては対応できない。また、誤った
単語が正しい単語から大きく異なるときは遅くなる。
我々が採用したのは、2番目のメカニズムを使い、別ファイルを使う方法である。こう
することによって、十分なメモリを持っているユーザーはとてもよい候補を得ることが
できるし、メモリが不足しているユーザーやスペルチェックだけで候補は出さなくてよ
いというユーザーはそれほどメモリを使わなくてすむ。
単語の頻度
候補をソートするにはどの単語が共通であるかを知ると役に立つ。理論的には単語の頻
度は単語とともに辞書の中に保持することができる。しかしそうすると単語につき回数
を保持しなければならない。これは単語ツリー圧縮を大いに劣化させる。また、全ての
言語に対して単語の頻度を保守するのは大変な作業である。
また、テキストに既に出てきている単語を優先するとよいだろう。このようにして特定
のテキスト内に表れる単語は候補の中で優先度が高くなる。
実装されたのは、表示中に単語を数えることである。ハッシュテーブルを使ってその単
語の回数を高速に検索する。回数は接辞ファイルでCOMMONアイテムにリストされている
単語から初期化される。そのため新規ファイルの編集を始めたときも機能する。
これは理想的ではない。Vimが長時間稼動しているほど回数は大きくなるためである。
しかし実用的には単語の回数を使わない場合に比べて注目に値するほどの改善である。
==============================================================================
4. 想定していること design-assumptions
変数のサイズ:
char 8 bit signed
char_u 8 bit unsigned
int 32 or 64 bit signed (限定された機能については16ビットもありうる)
unsigned 32 or 64 bit unsigned (16ビットについてはintと同様)
long 32 or 64 bit signed, can hold a pointer
Note いくつかのコンパイラは長すぎる行は文字列をうまく扱えない。C89の標準規格で
は509文字までに制限されている。
vim:tw=78:ts=8:noet:ft=help:norl:
VIMリファレンスマニュアル by Bram Moolenaar
Vimの開発 development
この文書は、Vimの更なる開発に参加しようという人にとって重要である。
1. 設計上の目標 design-goals
2. コーディングスタイル coding-style
3. 決定事項 design-decisions
4. 想定していること design-assumptions
ソースコードの概要については "src" ディレクトリのREADME.txtを見てください。
Vimはオープンソースソフトウェアです。誰でもVimの開発に協力できます。パッチを送
る時はなるべく "unified diff" 形式 ("diff -u" で作る) でお願いします。
GitHub上でプルリクエストを作ることも可能ですが、必須ではありません。
http://vim.wikia.com/wiki/How_to_make_and_submit_a_patch も見てください。
==============================================================================
1. 設計上の目標 design-goals
重要度の順に従って書かれている(大雑把であるが)。
かなりの項目が矛盾していることを注意しておく。これは故意である。それらの間で、
バランスを取っていかねばならない。
Vimは... Vi互換である design-compatible
何より、VimはViの気軽な置き換えとして使うことができるべきである。ユーザーが望
むなら、Vimは、オリジナルのViとの区別がほとんど付かない互換モードで使うことが
できる。
例外:
- 明白なViのバグをVimに再現しない。
- Viには異なるバージョンが存在する。私はバージョン3.7(6/7/85)を参考として
使っている。しかし、他のバージョンのサポートも可能な限り取り込まれる。
POSIXにおけるViのパートは、決定的な資料とは考えない。
- Vimは新しいコマンドを持つため、Viにないコマンドを入力しても機能してしまう
場合がある。
- VimはViの持っていない多くの特徴を持つ。VimからViへ戻ることは問題を引き起こ
すが、これは避けられないことである。
- いくつかの事柄はめったに使われた例がない(オープンモード、クラッシュ時の
e-mailの送信、など)。これらは、誰かが何らかの理由でそれを入れるべきだと考
え、さらにその機能が働き過ぎない場合に限って取り入れられる。
- いくつかの項目に関しては、Vi互換を保つべきかどうか、議論の余地がある。これ
らに関しては、オプションフラグが作られるだろう。
Vimは... 改良されている design-improved
Vimの改良点は、それをよりよいViにすべきであって、まったく違ったエディタに
してしまってはならない。拡張は "Viの精神" に従って行われる。
- 可能な限りキーボードを使う。マウスは私たちの持たぬ第３の手を必要とする。
多くの端末はマウスを備えていない。
- それでもマウスを使うようであれば、キーボードに切り替える必要をなくす。
マウスとキーボードの操作の混在を避けよ。
- コマンドとオプションを矛盾なく追加せよ。でなければ、それらを見つけ出し、思い
出すのに、人々は苦労を強いられるだろう。後々、さらにコマンドやオプションが
追加されることを忘れてはならない。
- 特性は、人々が知らなければ役に立たない。目立たない特性は追加しない、あるいは、
少なくともその特性が存在するというヒントをドキュメントに追加すること。
- CTRLや他の修飾子の使用は最小限に留めよ、これらはタイプしにくい。
- 多くの初心者、不慣れなVimユーザーがいる。Vimを使いはじめること、そしてより多
くを学んでいくことが、簡単にできるようにせよ。
- 特性は限りなく追加できる。新しく追加される特性は、(1)ユーザーが求めているこ
と、(2)実装にどれほどの労力が必要か、そして(3)誰かが実際に実装している、と
いったことに基づいて選択される。
Vimは... マルチプラットフォーム design-multi-platform
Vimは、可能な限り、多くのプラットフォーム上の多くのユーザーの助けでありたい。
- 多くの種類の端末をサポートする。最低限の要求は、カーソルの配置機能と画面の
クリアである。コマンドはたいていのキーボードが持つキーのみを使う。マッピン
グには、キーボード上の全てのキーを使うことができる。
- 多くのプラットフォームをサポートする。必要条件は、誰かがそのプラットフォーム
上でVimの開発をしたいと考えること、それによってコードに混乱をきたさないこと、
である。
- 多くのコンパイラとライブラリをサポートする。全ての人が、他のコンパイラや
GUIライブラリをインストールできるわけではないからである。
- 人々は、あるプラットフォームから別のプラットフォームへ、そしてGUIから端末
バージョンへ移行する。特性は全てのバージョン、あるいは、少なくとも理に叶った
労力でできる限りのバージョンで、提供されるべきである。ユーザーが能率的に仕事
を仕上げるために、プラットフォームを切り替えねばならないような事態は避けたい。
- いくつかのプラットフォームでは実現できない、または、ただひとつのプラット
フォームでしか実現できないような特性も、実装できないというわけではない。[こ
れは前項と故意に矛盾するものであり、両者の間でバランスが取られる。]
Vimは... 文書化されている design-documented
- 文書化されていない特性は、役に立たない。新しい特性を含んだパッチには、必ず
ドキュメントが含まれているべきである。
- ドキュメントは、わかりやすく、理解できるものであるべきだ。例を使うことが推
奨される。
- 文章を不必要に長くしてはならない。短い文章は、その項目を見つけやすくする。
Vimは... 高速で小さいサイズ design-speed-size
Vimを使うことで、システムリソースに大打撃を与えてはならない。Vimを小さく、
速く保つこと。
- コンピュータは年毎により速く、大容量になっている。Vimも成長しうるが、コン
ピュータの成長速度より速くなってはならない。Vimを古いシステム上でも使える
よう保つ必要がある。
- 多くのユーザーは、Vimを頻繁にシェルから立ち上げる。起動は短時間でなくてはな
らない。
- コマンドは能率的に働く必要がある。コマンドが消費する時間は、可能な限り短く
あるべきだ。役に立つコマンドなら、多少時間がかかってもよい。
- Vimを、遅い接続を通して使う人がいることを忘れてはならない。通信にかかるオー
バーヘッドは最小にすること。
- サイズがかなり大きく、多くの人によって使われるわけではない項目は、無効化で
きる特性とすべきである。
- Vimは、他のいろいろな構成要素の中にある、ひとつのコンポーネントである。巨大
なアプリケーションに変えてはならない、むしろ他のプログラムとよく協調するよう
にせよ。
Vimは... 保守性が高い design-maintain
- ソースコードは乱雑になってはならない。そして、信頼できるものでなくてはな
らない。
- 読みやすくするため、すべてのファイルで同じレイアウトを取ること
coding-style。
- 役に立つコメントをいれること！関数名と引数名を引用しても役に立たない。それ
が何のためにあるのか説明すること。
- プラットフォーム独立のコードに多くの変更を加える必要をなくし、他のプラット
フォームへの移植を簡単にできるようにすること。
- オブジェクト指向の精神を使う: データとコードを同じ場所に。コードの他の部分
に関する知識は最小で済むように。
Vimは... 柔軟である design-flexible
Vimは、そのユーザーに特定の作業パターンを強いるよりは、ユーザーの好むスタイル
での作業を支援すべきである。これは大きなインパクトをもつ項目(例えば、
'compatible' オプション)や、その他の詳細によって実現される。デフォルトは、多く
のユーザーがそのままのVimを楽しんで使えるように、慎重に選ばれている。コマンド
とオプションは、Vimをユーザーの希望と環境に調整するために使われる。
Vimは... こうではない design-not
- Vim はシェルでもオペレーティングシステムでもない。Vim はターミナルウィンドウ
を提供し、その中でシェルやデバッガを走らせることができる。例えば、ssh 接続越
しにこれをすることが可能だ。しかし、このようなものにテキストエディタが必要な
いなら守備範囲外だ (代わりに screen や tmux のようなものを使おう)。
風刺を込めて曰く: "Vim は Emacs のように流し台以外ならなんでもかんでも取り込
んでしまうようなことはしないが、Vim で流し台を洗うことはできるぞ。 ;-)"
Vim と gdb を連携させる方法については terminal-debugger を参照。他の(古い)
ツールは http://www.agide.org (リンク切れのようだ) と http://clewn.sf.net で
見つけることができる。
- Vimは、全てのプラットフォームに渡って調和を欠くという代償を払って、見栄えを
よくしようとする装飾的なGUIエディタではない。しかし、機能的なGUI特性は歓迎さ
れる。
==============================================================================
2. コーディングスタイル coding-style
Vimのソースコードに変更を加える際、守るべきルールがある。ソースを読めるもの、
保守できるものとして保つため、これらのルールに従って欲しい。
このリストは完全ではない。より多くの例は、ソースコードを見て欲しい。
コードリポジトリには editorconfig ファイルが含まれており、配布されている
editorconfig プラグイン editorconfig-install と一緒に使用し、推奨スタイルに
従うようにすることができる。
変更する style-changes
コードに変更を加える基本的なステップは:
1. GitHub からコードを取得する。これによりあなたが変更したコードをメインのコー
ドベースに同期するのがより簡単になる (あなたの変更がメインのコードベースに
含まれるようになるまで少しかかるかもしれない) 。
2. ドキュメントを調整する。最初にこれをやることで、あなたの行う変更がユーザー
に与える影響について、おおまかな印象をもつことができる。
3. ソースコードに変更を加える。
4. 変更がリストされた項目に影響を与えていないか、../doc/todo.txtをチェックす
る。
5. 新しい動作を検証し、将来的に問題が発生しないことを確認するために、
src/testdir にテストを追加する。
6. "git diff" でパッチを作成する。
7. 変更点について付記し、できれば問題と解決策についても記載すること。説明と差
分を添えて、vim-dev メーリングリストにメールを送信する。
些細な変更でない場合は、必ず github でプルリクエストを作成すること。これによ
り、テストスイートがトリガーされる。
Cコンパイラ style-compiler ANSI-C C89 C99
サポートされている最小の C コンパイラのバージョンは C89 (ANSI C とも呼ばれてい
る) である。C99 のような後継の標準規格はあまり普及していない、もしくは少なくと
も 100% サポートされているわけではない。したがって、C99 機能の一部のみを使用
し、一部を明示的に禁止する (これは時間の経過とともに徐々に調整される)。
使用してはいけない機能
これらの C99 の機能は、コンパイラのサポートが不十分なため使用してはいけない:
- 可変長配列 (C11 でもこれはオプショナルな機能である)。
- C99 の _Bool 型と _Complex 型。
- "inline" (ほとんど必要ない、コンパイラに最適化させよう。)
- フレキシブル配列メンバ: HP-UX C コンパイラはサポートしていない。(John
Marriott)
コメント style-comments
関数本体内に複数行のコメントを入れないようにすること。関数が非常に複雑で、一部
を個別にコメントする必要がある場合は、関数の構造を再検討する必要がある。
ファイルヘッダーと関数の説明には以下を使用:
/*
* Description
*/
* Description
*/
その他すべてには以下を使用:
// comment
インデント style-indentation
コードのインデントには 4 つのスペースを使用する。Vim を使用してソースを編集し
ている場合は、modeline があるため何もする必要はない。
他のエディタの場合は、リポジトリのルートに .editorconfig が提供される。
宣言 style-declarations
可能であれば、ガード内で for ループ変数を宣言する:
OK:
for (int i = 0; i < len; ++i)
間違い:
int i;
for (i = 0; i < len; ++i)
for (i = 0; i < len; ++i)
常にデフォルト値を持つ変数を宣言する:
OK:
int n = 0;
int *ptr = NULL;
int *ptr = NULL;
間違い:
int n;
int *ptr;
int *ptr;
括弧 style-braces
すべての波括弧は改行しなければならない:
OK:
if (cond)
{
cmd;
cmd;
}
else
{
cmd;
cmd;
}
{
cmd;
cmd;
}
else
{
cmd;
cmd;
}
間違い:
if (cond) {
cmd;
cmd;
} else {
cmd;
cmd;
}
cmd;
cmd;
} else {
cmd;
cmd;
}
OK:
while (cond)
{
cmd;
}
{
cmd;
}
間違い:
while (cond) {
cmd;
}
cmd;
}
ブロックがコメントを含めて 1 行の場合は、波括弧は省略できる。
OK:
if (cond)
cmd;
else
cmd;
cmd;
else
cmd;
間違い:
if (cond)
/*
* comment
*/
cmd;
else
cmd;
/*
* comment
*/
cmd;
else
cmd;
if/else の一方のブロックに波括弧がある場合は、もう一方のブロックにも波括弧
が必要である。
OK:
if (cond)
{
cmd;
}
else
{
cmd;
cmd;
}
{
cmd;
}
else
{
cmd;
cmd;
}
間違い:
if (cond)
cmd;
else
{
cmd;
cmd;
}
cmd;
else
{
cmd;
cmd;
}
if (cond)
{
cmd;
cmd;
}
else
cmd;
{
cmd;
cmd;
}
else
cmd;
OK:
while (cond)
cmd;
cmd;
間違い:
while (cond)
if (cond)
cmd;
if (cond)
cmd;
型 style-types
記述的な型を使用すること。それらのリストは src/structs.h ファイル内、またはお
そらく作業中のファイルの typedef 内にある。
Note すべてのカスタム型には「_T」という接尾辞が付けられることに注意
OK:
int is_valid_line_number(linenr_T lnum);
間違い:
int is_valid_line_number(unsigned long lnum);
空白と句読法 style-spaces
関数名と括弧の間に空白はない:
OK: func(arg);
間違い: func (arg);
if, while, switch 等の後には空白を入れること。
OK: if (arg) for (;;)
間違い: if(arg) for(;;)
コンマまたはセミコロンの後に空白を入れる:
OK: func(arg1, arg2); for (i = 0; i < 2; ++i)
間違い: func(arg1,arg2); for (i = 0;i < 2;++i)
'=', '+', '/' 等の前後に空白を入れる。
間違い: var=a*5;
OK: var = a * 5;
似たような動作をグループ化するには、空行を使う。
OK:
msg_puts_title(_("\n--- Signs ---"));
msg_putchar('\n');
msg_putchar('\n');
if (rbuf == NULL)
buf = firstbuf;
else
buf = rbuf;
buf = firstbuf;
else
buf = rbuf;
while (buf != NULL && !got_int)
間違い:
msg_puts_title(_("\n--- Signs ---"));
msg_putchar('\n');
if (rbuf == NULL)
buf = firstbuf;
else
buf = rbuf;
while (buf != NULL && !got_int)
msg_putchar('\n');
if (rbuf == NULL)
buf = firstbuf;
else
buf = rbuf;
while (buf != NULL && !got_int)
関数 style-functions
関数宣言は、戻り値の型を別のインデントされた行に記述して使用する:
OK:
int
function_name(int arg1, int arg2)
{
}
function_name(int arg1, int arg2)
{
}
間違い:
int function_name(int arg1, int arg2)
{
}
{
}
関数パラメータに意味のある名前を付ける。
共通関数を使う style-common-functions
よく使われる関数のうち、特別なVimバージョンを持つものがある。これらは理由あっ
て導入されたものなので、常にVimバージョンを使うように意識すること。
NORMAL NAME VIM NAME DIFFERENCE OF VIM VERSION
free() vim_free() NULLの解放をチェックする
malloc() alloc() アウトオブメモリの状況をチェックする
malloc() lalloc() alloc()に似ているが、long型の引数を持つ
strcpy() STRCPY() char_u *引数を、(char *)へキャストする
strchr() vim_strchr() スペシャルキャラクタを受け入れる
strrchr() vim_strrchr() スペシャルキャラクタを受け入れる
isspace() vim_isspace() 128以上のキャラクタを扱うことができる
iswhite() vim_iswhite() Tabとスペースに対してのみTRUE
memcpy() mch_memmove() オーバーラップしたコピーを扱う
bcopy() mch_memmove() オーバーラップしたコピーを扱う
memset() vim_memset() 全てのシステムで一定である
名前 style-names
関数の名前に31文字より長い名前は使えない。(VMSのために)
"delete" や "this" という名前の変数を使わないこと。C++で問題となる。
Vimができる限り多くのシステム上で走るという必要上、システムによってすでに定義
されている名前を使うことは避けねばならない。これは、問題となることが知られて
いる名前のリストである。名前はregexpパターンとして与えられている。
is.*() POSIX, ctype.h
to.*() POSIX, ctype.h
d_.* POSIX, dirent.h
l_.* POSIX, fcntl.h
gr_.* POSIX, grp.h
pw_.* POSIX, pwd.h
sa_.* POSIX, signal.h
mem.* POSIX, string.h
str.* POSIX, string.h
wcs.* POSIX, string.h
st_.* POSIX, stat.h
tms_.* POSIX, times.h
tm_.* POSIX, time.h
c_.* POSIX, termios.h
MAX.* POSIX, limits.h
__.* POSIX, system
_[A-Z].* POSIX, system
E[A-Z0-9]* POSIX, errno.h
.*_t POSIX, for typedefs, *_T を使うこと。
wait types.hとコンフリクトするため、関数の引数として使わない
index グローバル宣言を覆い隠す
time グローバル宣言を覆い隠す
new C++の予約語
clear Mac curses.h
echo Mac curses.h
instr Mac curses.h
meta Mac curses.h
newwin Mac curses.h
nl Mac curses.h
overwrite Mac curses.h
refresh Mac curses.h
scroll Mac curses.h
typeahead Mac curses.h
basename() GNU 文字列関数(GNU string function)
dirname() GNU 文字列関数(GNU string function)
get_env_value() Linux システム関数
その他 style-various
マクロ定義はすべて大文字にする:
#define SOME_THING
機能に関する定義は "FEAT_" で始める:
#define FEAT_FOO
'\"' を使わない、あるコンパイラはこれを扱えない。'"' はうまく機能する。
以下を使ってはならない:
#if HAVE_SOME
あるコンパイラはこれを扱えず、"HAVE_SOME" が定義されていないと訴える。
以下を使う
#ifdef HAVE_SOME
または
#if defined(HAVE_SOME)
スタイル style-examples
１行に１つのステートメント。
間違い: if (cond) a = 1;
OK: if (cond)
a = 1;
間違い: while (cond);
OK: while (cond)
;
間違い: do a = 1; while (cond);
OK: do
a = 1;
while (cond);
==============================================================================
3. 決定事項 design-decisions
折り畳み(folding)
同じバッファにいくつもの折り畳み状態を設定可能にする。例えば、あるウィンドウに
関数を折り畳んだ状態で表示し、他のウィンドウで関数の中身を表示するなど。
折り畳みはテキストを表示する方法である。テキストを変更すべきではない。したがっ
てバッファ内のテキストをウィンドウに表示する際のフィルタとして実行される。
ウィンドウの名前
"ウィンドウ" という単語は一般にいくつかの意味で使われている。スクリーン上のウィ
ンドウ、xtermのウィンドウ、Vimのバッファを表示するウィンドウなど。
混乱を避けるため、時にウィンドウと呼ばれる他の物には別の名前が付けられている。
ここに関連する物の概観を示す。
スクリーン(screen) ディスプレイ全体。GUIでは例えば1024x768ピクセルの画
面。Vimシェルはスクリーン全体を使うことも一部を使う
こともできる。
シェル(shell) Vimアプリケーション。スクリーン全体(例えばコンソール
で実行した時)、あるいはその一部(xtermやGUI)。
ウィンドウ(window) バッファの表示画面。Vimは複数のウィンドウを持つこと
ができる。ウィンドウはコマンドラインやメニューバー、
ツールバーなどといっしょに表示される。これらはシェル
に納まる。
スペルチェック develop-spell
Vim にスペルチェックを追加することになったとき、利用可能なスペルチェックのライ
ブラリやプログラムについて調査が行われた。その結果は残念なことに、Vim 内でスペ
ルチェックエンジンとして使えるものはないとわかった。これには様々な理由がある:
- マルチバイトエンコーディングをサポートしていない。1つのファイル内で複数の言
語を使えるようにするために、少なくとも UTF-8 はサポートしていなければならな
い。
オンザフライな変換は常に可能とは限らない(iconv に対応している必要がある)。
- プログラムとライブラリに対して: それらをそのまま(as-is)使うには、Vim と別個
にインストールしなければならない。これはたいてい不可能ではないが、難点である。
- パフォーマンス: いくつかのテストによると、スペルチェックを構文強調のようにオ
ンザフライで(再描画中に)行うことは可能であった。しかし他のコードで使われたメ
カニズムはもっと遅かった。例えば、Myspell はハッシュテーブルを使用する。ほと
んどのスペルチェッカが使用している接辞圧縮を使うと遅くなった。
- aspell のような外部プログラムを使うには、通信メカニズムを用意しなければなら
ない。これをポータブルな方法で行うのは複雑過ぎる(Unix だけなら比較的簡単だが、
それでは十分ではない)。そしてパフォーマンスが問題になる(何回ものプロセス切替
が行われる)。
- "Etten-Leur" や "et al." など、単語でない単語のサポートを欠いている。そのた
めこれらの部分を OK とマークしなければならないが、そうすると信頼性が低下する。
- 地域や方言のサポートを欠いている。英語の単語をすべて受け付け、カナダ語でない
単語を別に扱うことが難しくなる。
- 頻度が低い単語のサポートを欠いている。正しいがめったに使われないたくさんの単
語が、よく使われる単語のスペルミスとみなされてしまう。
- スペル候補を作成するには速度はそれほど重要ではなく、他のプログラムやライブラ
リをインストールすることは許容できる。しかし、単語リストが異なるとスペル候補
が誤単語になってしまう。
スペル候補 develop-spell-suggestions
候補の作成には2つの基本的なメカニズムがある:
1. 誤った単語を少し変更して正しい単語とマッチするかチェックする。あるいは、正
しい単語全てに対し、それを少し変更して誤った単語とマッチするかチェックする。
変更とは、文字の削除・文字の挿入・2つの文字の交換などである。
2. 誤った単語と正しい単語のリストの両方に soundfolding (発音が近い単語を同じグ
ループとみなすこと) を行って、そこでマッチを見つける。1番目のメカニズムと同
様にいくつか変更をしてもよい。
最初のメカニズムはタイプミスを見つけるのにはよい。ハッシュテーブルの実験と、他
のスペルチェッカのソリューションを見ると、これにはtrie(ツリー構造の一種)が最適
であるとの結論になった。メモリ使用量の削減と、賢い変更を試みるということの両方
の面でである。例えば、文字を挿入するときは正しい単語につながる文字だけを試せば
よい。他の(ハッシュテーブルを使った)メカニズムは、単語のすべての位置で、ありう
るすべての文字を試さねばならない、また、ハッシュテーブルを使うには、単語の境界
が個別に認識されなければならないのに対し、trie はそれを要求しない。そのためメ
カニズムがより単純になる。
ある単語の発音は知っているがスペルを知らないという場合に soundfolding は有用で
ある。例えば、"dictionary" という単語を "daktonerie" と書いてしまうかもしれな
い。これを最初の方法で訂正しようとすると変更回数が非常に多くなってしまい、正し
いスペルを見つけるのは困難である。それに対し、これらの単語にsoundfoldingを行う
と "tktnr" と "tkxnry" になり、2文字しか違わない。
soundfoldの同値(音が似ている単語)により単語を見つけるには全てのsoundfolded
wordsのリストが必要である。どれが最良の方法かを探すための実験が行われた。案:
1. 修正候補を探すときに、その場でsound foldingを行う。つまり、正しい単語のtrie
をたどりながら、各単語をsoundfoldingし、それがスペルミスしている単語からど
れだけ異なるかをチェックする。これはメモリ効率の面でとても優れているが、時
間は長くかかる。英語の場合、高速なPCで2秒ほどかかる。これは対話的な利用とし
て受け入れられる。しかしいくつかの言語(ドイツ語、カタルニャ語など)に対して
は10秒以上かかり、受け入れがたい。バッチ処理(自動訂正)に使うには全ての言語
で遅すぎる。
2. soundfoldされた単語に対してtrieを使い、soundfoldingなしのときとまったく同じ
ように検索できるようにする。そのためには、soundfoldされた各単語に対し、正し
い単語のリストを記憶しておく必要がある。そうすると照合がとても高速になるが、
1MB〜10MBのオーダーの大量のメモリを必要とする。ある言語の場合は元の単語のリ
ストよりも多くなる。
3. 2番目の案と同様だが、接辞圧縮を使い、soundfoldした基本単語だけを保存するこ
とによりメモリ消費量を減らす。これはAspellが採用している方法である。不利点
は、誤った単語をsoundfoldする前に接辞を取り除いておかねばならないことである。
そのため、単語の先頭・末尾における誤りに対しては対応できない。また、誤った
単語が正しい単語から大きく異なるときは遅くなる。
我々が採用したのは、2番目のメカニズムを使い、別ファイルを使う方法である。こう
することによって、十分なメモリを持っているユーザーはとてもよい候補を得ることが
できるし、メモリが不足しているユーザーやスペルチェックだけで候補は出さなくてよ
いというユーザーはそれほどメモリを使わなくてすむ。
単語の頻度
候補をソートするにはどの単語が共通であるかを知ると役に立つ。理論的には単語の頻
度は単語とともに辞書の中に保持することができる。しかしそうすると単語につき回数
を保持しなければならない。これは単語ツリー圧縮を大いに劣化させる。また、全ての
言語に対して単語の頻度を保守するのは大変な作業である。
また、テキストに既に出てきている単語を優先するとよいだろう。このようにして特定
のテキスト内に表れる単語は候補の中で優先度が高くなる。
実装されたのは、表示中に単語を数えることである。ハッシュテーブルを使ってその単
語の回数を高速に検索する。回数は接辞ファイルでCOMMONアイテムにリストされている
単語から初期化される。そのため新規ファイルの編集を始めたときも機能する。
これは理想的ではない。Vimが長時間稼動しているほど回数は大きくなるためである。
しかし実用的には単語の回数を使わない場合に比べて注目に値するほどの改善である。
==============================================================================
4. 想定していること design-assumptions
変数のサイズ:
char 8 bit signed
char_u 8 bit unsigned
int 32 or 64 bit signed (限定された機能については16ビットもありうる)
unsigned 32 or 64 bit unsigned (16ビットについてはintと同様)
long 32 or 64 bit signed, can hold a pointer
Note いくつかのコンパイラは長すぎる行は文字列をうまく扱えない。C89の標準規格で
は509文字までに制限されている。
vim:tw=78:ts=8:noet:ft=help:norl: