私は, プラグインに同包されているシンタックスファイルが気に喰わないことが度々あった. 例えばunite.vimの選択色とvimfilerの選択色が異なったり, unite-lineの行番号がLineNrで色付けされてなかったり, vimshellでls -lの時間のあたりの色付けが滅茶苦茶だったり, vimfilerの一番上の現在のパスの色と, vimshellのpromptのパスの色が異なったりするわけだ. (Shougoさんばかりごめんなさい...)
思い返せば, vimshellのls -lの色(特に時間の辺り)が気に喰わないのがシンタックスファイルを書き始めたきっかけだった.
そもそも, 自分の身に合うカラースキームを見つけるのは骨が折れる. 或いは, スクリーンショットは良さげでも, 使ってみたらなんだか違う, みたいな感想を持つことも多い. CUIのことを考えていないものもある.「ここのこの色だけは別の色にしておきたいなぁ」みたいなことで, 色の設定を.vimrcに書いてしまう. しかし, そういう設定が増えだすと, もう自分で書いてしまえ, となるのである.
Vimのカラースキーム/シンタックスファイルは, 自作することをお勧めする. 書き方とかはいちいちここには書かない. ヘルプ:h syntaxとか, プラグインに同包されているコードを見てほしい. Vimのシンタックスの仕組みはよく出来ていて, contains, contained, nextgroupなどを駆使することで, 非常に強力な色付けをすることができるようになっている.
自分が今使(作)っているのはitchyny/landscape.vimである. 気に入らない所はコロコロ変えてるので, 最近頻繁に更新している. その機能と, 色を決めるコツの一例を紹介しよう. (以下は, この記事時点のものであり, 将来変更される可能性が十分にある, というか多分変更される)
シンタックスの基本要素
:h group-nameで出てくるものに対して, どういう色にすればよいかを書いてみる事にする. (私は色彩の専門家でも何でもないので, トンデモ理論であることに注意してほしい)
背景と文字色
背景は真っ黒, 普通の文字の色は真っ白にしている. 結局, これが一番見やすいという結論に至った. 確か, GUI用には#ddddddを使っていると思うが, GUIの真っ白がなんか眩しすぎるからだと思う. 真っ青にしてる人は結構見るが, よくもまぁ作業できるなぁと思う. 背景をグレーにすると, 色の幅が狭くなって認識しにくくなる. ただ, 目が疲れるという意見も分からんでもない.
(以下, キャプチャーはCUI版のVim(256色)の表示結果である. 実際の見え方と, キャプチャー結果に若干のズレがあることを, 了解いただきたい.)
コメントは背景色と文字色の間で決める
コメントはあらゆる言語で現れる. その色は統一されているべきである. コメントは「カラー」があってはならないし, 読みにくすぎてもいけない. 背景色と文字色のちょうど中間, やや背景色寄りを使うと良いだろう. 私があまりコメントを読むことがないからだろうか...?
構文の要素は背景色に近い原色, 文字列は普通の文字に近い色
当然のことだが, 背景に近い暗い色は見難く, 文字色に近い明るい色は見やすい. 「if」「#define」などの構文の要素は, その構文であることが分かればよく文字の見やすさが要求されないので, 背景に近い原色で良い. 一方, 文字列は何が書いてあるかが重要なので, 読めなくてはいけない. よって, 明るい色にするのである.
C言語の「static int」「const char」なども, 「static」「const」などは「int」「char」よりも背景色に近い色を使う. 後者のほうが大事だからである.
まとめると, 「文字列のように読まなくてはいけないものは白く, ifやwhileのようにシンボルなのは背景に近づけよ」ということである.
数字は原色に近く明るく, Booleanはもっと目立つ色で
数字は目立つべきである.
構文よりも, やや明るい色が良いと思う.
更に, Booleanはもっともっと目立つべきである.
そもそもBooleanの即値をプログラムのコードに書くことはない気がする. 追記: そんなことはない。
TODOは刺激的に
TODOは直してしかるべき. 思いっきり注意を喚起しよう.
vimfiler
データに何をするかで色分けして
ファイルというのは, それに対して何をするかが色いろある.
- ディレクトリ→その場所に移動する
- ソースコード→編集する
- 画像ファイル→ビューワーで見る
- pdf→ビューワーで開いて読む
- 圧縮ファイル→解凍する
- log, swpファイル→編集することはまずない
この, 何をするかで色分けすると良い. 特に, 論文をよく読むので, pdfファイルだけは色分けしたかった.
vimshell
コマンドごとにregionを作る
lsをした時はls用のシンタックス, gitした時はgit用のやつという風にする. シェルスクリプトとかに書かれていたら元も子もないが, あらゆる場所で色んなmatchをさせようとすると, cat ~/.vimrcするだけでものすごく時間がかかるようになってしまう. でも, diffなどはきちんと色を付けてほしい. あらゆる要素をcontainedにし, コマンドごとにcontains=するのである.
ls -lはvimfilerと同じ色に
基本. と言うか, 最初はこれがしたかった. ただ, -lなしの時の完璧な色付けは難しい.
先ほどのvimfilerのキャプとくらべて, 時間の色が対応していることに気がついてほしい.
Error, Warningは派手に
「あらゆる要素をcontained」といったが, エラーだけは至る所で出てくる. こういうものは, 無条件にマッチさせてやれば良い.
unite.vim
Unite fileはvimfilerっぽく
ただし, あまり色々し過ぎると重くなるので注意. あと, executableかどうかは, 構文だけ触っていたらハイライトできない.
vimshellのhistoryはコマンドラインのシンタックスで
最初のワードはコマンドで, みたいにする.
Shougoさんにとっては, 高速に絞り込めるというのが一番の目的だろうから, こういう速度を低下させるような色付けはお好きじゃないんだと思う. 正規表現の処理系が100倍位高速でVim Scriptはコンパイルして自分にリンクしてから実行するような超高速Vim現れないかなー...
unite-lineはLineNrを使って
意味的に同じものなら, 同じ色っていうのが基本かなぁと思う.
まとめ
カラースキーム/シンタックスファイルは自分で書こう. 自分で書いたら, 自分なりに快適になっていくだろうし, 自分がどういうところに着目して見たいかが分かって良い. 人によって色に対する感性も異なるから, あまり人が作ったものが快適と思わないほうがいい. 良い道具というのは自分で磨くものなのである.
昔にやっていたプロジェクトのファイルを開くと, 既視感と共に, 当時とのカラースキームの変化に新鮮さを感じる. カラースキームを自分で書いていると, 他人の書いたものに乗り移ることがなくなる.
カラースキームとの長ーーーーいお付き合い, 始めませんか.
