*design-goals*重要度の順に従って書かれている(大雑把であるが)。かなりの項目が矛盾していることを注意しておく。それらの間で、バランスを取っていかねばならない。*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互換を保つべきかどうか、議論の余地がある。これらに関しては、オプションフラグが作られるだろう。*design-improved*Vimの改良点は、それをよりよいViにすべきであって、まったく違ったエディタにしてしまってはならない。可能な限りキーボードを使う。マウスは私たちの持たぬ第3の手を必要とする。多くの端末はマウスを備えていない。それでもマウスを使うようであれば、キーボードに切り替える必要をなくす。マウスとキーボードの操作の混在を避けよ。コマンドとオプションを矛盾なく追加せよ。なければ、それらを見つけ出し、思い出すのに、人々は苦労を強いられるだろう。後々、さらにコマンドやオプションが追加されることを忘れてはならない。特性は、人々が知らなければ役に立たない。少なくともその特性が存在するというヒントをドキュメントに追加すること。CTRLや他の修飾子の使用は最小限に留めよ、これらはタイプしにくい。多くの初心者、不慣れなVimユーザーがいる。Vimを使いはじめること、そしてより多くを学んでいくことが、簡単にできるようにせよ。特性は限りなく追加できる。新しく追加される特性は、(1)ユーザーが求めていること、(2)実装にどれほどの労力が必要か、そして(3)誰かが実際に実装している、といったことに基づいて選択される。*design-multi-platform*Vimは、可能な限り、多くのプラットフォーム上の多くのユーザーの助けでありたい。多くの種類の端末をサポートする。最低限の要求は、カーソルの配置機能と画面のクリアである。コマンドはたいていのキーボードが持つキーのみを使う。マッピングには、キーボード上の全てのキーを使うことができる。多くのプラットフォームをサポートする。必要条件は、誰かがそのプラットフォーム上でVimの開発をしたいと考えること、それによってコードに混乱をきたさないこと、である。多くのコンパイラとライブラリをサポートする。全ての人が、他のコンパイラやGUIライブラリをインストールできるわけではないからである。人々は、あるプラットフォームから別のプラットフォームへ、そしてGUIから端末バージョンへ移行する。特性は全てのバージョン、あるいは、少なくとも理に叶った労力でできる限りのバージョンで、提供されるべきである。ユーザーが能率的に仕事を仕上げるために、プラットフォームを切り替えねばならないような事態は避けたい。いくつかのプラットフォームでは実現できない、または、ただひとつのプラットフォームでしか実現できないような特性も、実装できないというわけではない。[これは前項と故意に矛盾するものであり、両者の間でバランスが取られる。文書化されていない特性は、役に立たない。新しい特性を含んだパッチには、必ずドキュメントが含まれているべきである。ドキュメントは、わかりやすく、理解できるものであるべきだ。文章を不必要に長くしてはならない。短い文章は、その項目を見つけやすくする。*design-speed-size*Vimを使うことで、システムリソースに大打撃を与えてはならない。コンピュータは年毎により速く、大容量になっている。Vimも成長しうるが、コンピュータの成長速度より速くなってはならない。Vimを古いシステム上でも使えるよう保つ必要がある。多くのユーザーは、Vimを頻繁にシェルから立ち上げる。起動は短時間でなくてはならない。コマンドは能率的に働く必要がある。コマンドが消費する時間は、可能な限り短くあるべきだ。役に立つコマンドなら、多少時間がかかってもよい。Vimを、遅い接続を通して使う人がいることを忘れてはならない。通信にかかるオーバーヘッドは最小にすること。サイズがかなり大きく、多くの人によって使われるわけではない項目は、無効化できる特性とすべきである。Vimは、他のいろいろな構成要素の中にある、ひとつのコンポーネントである。巨大なアプリケーションに変えてはならない、むしろ他のプログラムとよく協調するようにせよ。ソースコードは乱雑になってはならない。信頼できるものでなくてはならない。読みやすくするため、すべてのファイルで同じレイアウトを取ること|coding-style|。役に立つコメントをいれること!関数名と引数名を引用しても役に立たない。それが何のためにあるのか説明すること。プラットフォーム独立のコードに多くの変更を加える必要をなくし、他のプラットフォームへの移植を簡単にできるようにすること。データとコードを同じ場所に。コードの他の部分に関する知識は最小で済むように。*design-flexible*Vimは、そのユーザーに特定の作業パターンを強いるよりは、ユーザーの好むスタイルでの作業を支援すべきである。オプション)や、その他の詳細によって実現される。デフォルトは、多くのユーザーがそのままのVimを楽しんで使えるように、慎重に選ばれている。コマンドとオプションは、Vimをユーザーの希望と環境に調整するために使われる。シェルでもオペレーティングシステムでもない。中でシェルを走らせたりデバッガを制御したりできるようにはならない。コンポーネントとして使おう。流し台を洗うことはできるぞ。Vimは、全てのプラットフォームに渡って調和を欠くという代償を払って、見栄えをよくしようとする装飾的なGUIエディタではない。機能的なGUI特性は歓迎される。*coding-style*Vimのソースコードに変更を加える際、守るべきルールがある。保守できるものとして保つため、これらのルールに従って欲しい。このリストは完全ではない。多くの例は、ソースコードを見て欲しい。(あなたの変更がメインのコードベースに含まれるようになるまで少しかかるかもしれない)。ついて学ぶ必要がある。ユーザーフレンドリーなツールではない。ドキュメントを調整する。最初にこれをやることで、あなたの行う変更がユーザーに与える影響について、おおまかな印象をもつことができる。ソースコードに変更を加える。変更がリストされた項目に影響を与えていないか、../doc/todo.txtをチェックする。