こんにちは、ujihisaです。無事引っ越しが完了しましたが、インターネット回線の確保にはもうしばらく時間がかかるらしく、しばらく家でオフラインな状態です。ちなみに来日することが決まりました。こんなカンファレンスや、勉強会を企画してみました。いずれも来月です。

問題

Vim使いの大半は、Vimをフルスクリーンで使っていることと思います。このとき、WindowのfocusがVimの窓にあるときは別に構わないのですが、focusがVimの外にあるときに、つねに背景がVimになってしまいます。せっかくファンシーなデスクトップの壁紙を設定しているのに、システム起動直後と終了直前にしか見れないのは、いささか寂しいものです。

解決

VimにはFocusGainedとFocusLostというイベントがあります。これを用いてVimの透明度を変更すると、とてもいい感じになります。 参考までに、著者のMacVimのための設定を以下に掲載します。~/.vimrcではなく~/.gvimrcに記述してください。

augroup hack234
  autocmd!
  if has('mac')
    autocmd FocusGained * set transparency=10
    autocmd FocusLost * set transparency=50
  endif
augroup END

普段は透明度10 (ほとんど不透明)にしており、focusがないときは透明度50 (かなり透明) にしています。筆者のGentoo上のGVimは'transparency'をサポートしていないため、if has('mac')で条件分岐しています。

追記

mattnさんがWindows版GVimでも動作するためのプロジェクトを発動させたようです。

• https://github.com/mattn/transparency-windows-vim

ujihisa

こんにちは、ujihisaです。今月末に引っ越しをする予定があり、毎日忙しく、Vimを使う暇すらない日々が続いています。

問題

美しいColorSchemeを使用しており、それを友達に自慢したいVim使いは多数いると思います。しかしながら、現在使用中のColorSchemeの名前を取得する方法が分からず、はがゆい思いをしたことがある人も少なくないのではないでしょうか。

解決

二つの方法があります。

:colorscheme

あるいは

:echo g:colors_name

前者は画面にColorScheme名を表示する専用のコマンド、後者はColorScheme名が入っている変数を得てそれを表示しているわけですので、対話的に使用するときは前者を、Vim scriptから値を使用するときは後者を使うと自然になります。

注意

必ずしも上記方法で現在使用中のColorSchemeが得られるとは限りません。ColorScheme開発者には、そのColorScheme名をg:colors_nameというグローバル変数に格納することが推奨されていますが、自動的に行われるわけではありません。

上記のような場合、:colorschemeは無条件にdefaultと出力します。また、g:colors_nameにアクセスするとエラーを吐き出します。

悪評高いColorSchemeの例としてleoがあります。:colorscheme leoして:echo g:colors_nameないし:colorschemeして、絶望しましょう。

そして、パッチを投げましょう。

ujihisa

こんにちは、ujihisaです。11月くらいに来日する予定で、そのときに大規模なVimの勉強会などを開催したいと思っています。発表をしてみたい方は、気軽に @ujm などに英語で連絡ください(*1) 。

問題

VimでMarkdown形式の文書を書くための記事を2年ほど前に執筆し、こちらで公開していました。

• Hack #52: Markdown形式の文書を書く

ところで先月quickrun version 0.5.0 がリリースされました。その際大きな仕様変更がありました。それについては下記の記事に詳しく掲載されています。

• quickrun 0.5.0がリリースされました

先ほどのHack #52の記事に掲載されている情報のままでは、Markdown形式で執筆中のバッファの内容をHTMLに変換してブラウザで開くことができません。どのようにすればよいのでしょうか。

解決 (1/2)

quickrun 0.5.0はデフォルトで4種類のmarkdown変換機をサポートしています。

• Markdown.pl (Perl. cpan install Markdownかな?)
• kramdown (Ruby. gem install kramdown)
• bluecloth (Ruby. gem install bluecloth)
• redcarpet (GitHubなどで使われている悪評高いMarkdownエンジン)
• pandoc (Haskell. cabal install pandoc)

もしも$PATHに上記のコマンドがあれば、それを用いて変換します。優先順位はこの一覧と同じです。

したがって'filetype'がmarkdownであるようなバッファを編集中に:QuickRunすると、上記コマンドのいずれかが呼ばれ、そして編集中バッファをhtmlに変換したものをquickrunウインドウに表示します。なので、この出力先をbufferではなくbrowserにすればそれで問題が解決されます。

~/.vimrcに以下の設定を記述します。

let g:quickrun_config['markdown'] = {
      \ 'outputter': 'browser'
      \ }

ただし、もしもこれまでg:quickrun_configを全く使った事がない自信があるならば、以下の行をその前に記述してください。

let g:quickrun_config = {}

続いてopen-browser.vimがインストール済みかどうか確認します。インストールしていなければ、すぐにいれましょう。

これで'filetype'がmarkdownなバッファから:QuickRun (あるいはデフォルトのキーマッピングである\rの打鍵) で、新しいウインドウが分割されてHTMLが出力されるかわりに、ブラウザが立ち上がってそちらにHTMLがきれいに表示されるはずです。

解決 (2/2)

大抵の方は(1/2)の時点で大丈夫なのですが、しかしASCIIの範囲内に収まらない文書を書く一部の人は、pandocでMarkdownをHTMLに変換した後に、文字化けしたHTMLを見てしまったのではないでしょうか。

この場合はpandocの-sオプションを用います。

let g:quickrun_config['markdown'] = {
      \ 'outputter': 'browser',
      \ 'cmdopt': '-s'
      \ }

おっとしかしpandoc以外でも-sを使われると困ります。間違ってredcarpetなどをインストールしてしまうと、なぜかそちらの方が高い優先度をもっているため、そちらを使われてしまうのです。ここはpandocを使用するよう強制してみましょう。

let g:quickrun_config['markdown'] = {
      \ 'type': 'markdown/pandoc',
      \ 'outputter': 'browser',
      \ 'cmdopt': '-s'
      \ }

実はこのあたりは詳しくはquickrun公式ヘルプに掲載されています。詳しくは:h quickrun-examplesをご覧ください。

補足

現在開発中のquickrun 0.5.1では新機能”hook”というものがつくそうです。いまから楽しみですね!

脚注

• *1 スペイン語も勉強中ですので、対応可能です。

ujihisa

問題

Vimで文書を開いているとしばしばURLが記載されていて、 その度にURLをクリップボードにヤンクしてブラウザのアドレスバーにペーストして…と、とても面倒です。 ファイルパスならgfや<C-w>fで開けますが、 URLを開くマッピングは用意されていません。 どうすればいいでしょうか。

解決

open-browser.vimを使います。 まずプラグインをインストールし、次の設定を.vimrcに書きます。

let g:netrw_nogx = 1 " disable netrw's gx mapping.
nmap gx <Plug>(openbrowser-smart-search)
vmap gx <Plug>(openbrowser-smart-search)

そしてURLの上にカーソルをのせてgxをタイプするとそのURLをブラウザで開けます。 またgxが思った通りのURLを開いてくれない場合、ヴィジュアルモードでそのURLを選択してからgxをタイプすると選択した通りのURLが開けます。 詳しくは:help open-browserを参照してください。

tyru

この記事について

この記事は、開発環境勉強会における「Vimテクニックバイブル」紹介スライドの完全版です。 「Vimテクニックバイブル」については、taku_oさんやmattnさんなども記事を書いていますが、 私の場合はできるだけ本の内容に触れたものにしています。 これを読んでVimテクニックバイブルを購入していただける人が増えれば、著者達にとって最高の喜びです。

Vimテクニックバイブルができた背景

以前にもブログの記事で触れていますが、Vim界には良質な記事や書籍が不足しています。 特に、まともにVim scriptを書ける人が書いた書籍がほとんどありません。 これはVim界の大きな損失であり、Vim scriptプログラマーが育たない大きな原因となっています。 私がVim勉強会に参加すると、必ずといっていいほど聞かれるのが 「Shougoさんは、Vimの書籍を書かないんですか？」ということです。 この声になかなか答えられないのは悲しいものがありました。

と、いうことで……今年ついにVimの書籍が刊行されます！ 書名は「Vimテクニックバイブル」です。 中身は「Emacsテクニックバイブル」のVim版となっており、イメージカラーは当然Vimグリーンです。 そういえば、EmacsテクニックバイブルはEmacsブルー(パープル)でしたね。 キャッチコピーは、「unite.vimで進化する新しいVimの常識を教えます。あなたはVimの本当の姿を知っていますか？」 Emacsテクニックバイブルとは違い、unite.vimを全面に押し出しています。

執筆者紹介

執筆陣はかなり豪華です。おそらく、これだけの人達が一冊の書籍を作るために集まることはもうないでしょう。

taku_o

人気サイト「名無しのVim使い」の管理人です。雑誌にVimの記事を執筆したことがあります。 サイトで紹介しているだけあって、様々なプラグインについて、かなりの知見を持っています。

yukimi

章の基礎知識や用語の統一など、細かいところで手伝ってもらっています。Vim使いです。

mattn

webapi-vimやzencoding.vimの作者です。他にも細かなプラグインを作っています。 KaoriYaさんと同じく、昔からVimにパッチを多数送っており、Vimの内部実装や黒魔術に詳しいです。

thinca

quickrunやref.vim, scouter.vimなどの作者です。unite.vimのsourceやvital.vim, eskk.vimなどにも関わっています。 Vim scriptにかなり詳しいです。

fuenor

QFixHowm, QFixGrep, JPFormat.vimの作者で、Vim-UTF8を配布しています。 Windows環境での日本語の扱いについて詳しいです。

Shougo

neocomplcache, vimshell, vimproc, unite.vim, vimfilerなどを作っています。 メンテナンスしているプラグインが多すぎて、なかなか時間が足りないのが悩みです。Vimは環境だと思っています。

内容紹介

もう執筆がほぼ終わっているため、中身は確定しています。プラグインの紹介を中心とした豪華な内容となるようにしました。 紹介しているプラグインは定番からマイナーまで幅広く、作者自ら解説していることもあります。 まだ発売まで期間があるため、詳しい目次を挙げることはできませんが、以下のような内容が含まれています。

vimfiler

vimfilerの使い方や、キーマッピング、マニアックなところではvimfilerを用いた拡張リネーム機能について解説しています。

netrw

netrwによる遠隔地ファイル編集、netrwによるブックマーク、netrwによるファイル操作が解説されています。

quickrun

quickrunの使い方、各種オプション、設定方法について解説されています。

ref.vim

ref.vimの使い方、各種sourceについて解説されています。

vimshell(インタプリタ通信機能を含む)

vimshellの使い方、よく使われる内部コマンド、vimshellのインタプリタ通信機能を解説しています。 ちなみに、Emacsテクニックバイブルでは、eshellについて触れられていません。

Conque

Vimで端末を実現するプラグインであるConqueの使い方、vimshellとの違いについて解説しています。

skk.vim

SKKについて解説しています。eskk.vimも少しだけ書いてあります。それほどページはありません。

neocomplcache

neocomplcacheの使い方、設定方法、neocomplcacheのスニペット機能、スニペットの書き方、 neocomplcacheのsourceの作り方と、大変豪華な内容となっています。 以前Vim Hacksに書いた内容の完全版と言っても良いでしょう。

zencoding.vim

zencoding.vimの基本から、任意の言語への応用例まで挙げられています。

QFixHowm

QFixHowmの使い方、メモの作成方法、メモの検索、ToDo管理について解説されています。

QFixGrep

Windows環境のgrepの注意点についても解説されています。

JPFormat.vim

JPFormatによる日本語の整形方法について解説されています。

autodate.vim

webapi-vim

VimからWebサービスを扱う方法について解説されています。

project.vim

project.vimによるプロジェクト管理やproject.vimの設定方法について解説されています。

Vim scriptが分からない初心者でも安心！

Vimの設定や、Vim pluginについての解説を中心とした書籍となっていますが、 ある程度のVim scriptの知識は必要不可欠です。 そこで、次のような項目について解説しています。 これ以上の詳しい解説については、Vimのヘルプを参照してください。

:helpの読み方

Vimの:helpをすぐに引けるかどうかは、初心者と初級者を分ける大変重要なファクターとなっています。 この本では、Vimの:helpの使い方について解説しています。

Vim script基礎文法最速マスター(改訂版)

これは、thincaさんが以前ブログで書いていた「Vim script基礎文法最速マスター」の改訂版です。 Vim scriptについて一通り学ぶことができます。

マッピングについて

Vimのキーマッピングは大変ややこしいですが、詳しく解説しています。

オプションについて

Vimのオプションには落とし穴が多数あります。Vimのオプションにおける仕様について解説しています。

Vimプラグインの管理

Vimのプラグインをインストールするなら、パッケージマネージャは必要不可欠です。 定番のVundle, pathogenから、vimballに至るまで解説をしています。

テキストオブジェクト

最近のVimを語るにはなくてはならない機能です。 テキストオブジェクトの拡張についても触れられています。

QuickFix

grepやmakeには欠かせない機能です。

:autocmd

外部インタフェース

ちょっとレベルが高いですが、Perl, Pythonの外部インタフェースについて解説されています。

最近のVimといえば、unite.vimは外せないよね！

当然unite.vimについては、1つのChapterを贅沢に使用して解説しています。 Emacsテクニックバイブルはanything.elについて2つのChapterを使っているので、そちらよりは若干量が減ります。 それでも、30ページくらいはあるため、十分満足できると思います。 unite.vimの章では、次の内容を解説しています。 これを読めばあなたもunite.vimマスターに！

vimfiler, vimshellなどといった他のプラグインとの連携

unite.vimの有用なsource

カスタマイズ方法についての解説

unite.vimの各種オプションについて、解説しています。 マニアックなところでは、buffer-name-optionについての解説もあります。

source, kind, action, filterの解説

特にsourceを自作する場合、source, kind, action, filterの概念は重要です。それぞれの仕様について詳しく解説しています。 作者が自ら書いているため、情報が正確で安心です。

sourceの作り方まで載っている！

サンプルsourceの作り方が書いてあります。マニアックなところでは、非同期sourceの仕様についても書いています。

unite.vim Ver.2.2対応(一応)

一応最新版のunite.vimの仕様に準拠しています。残念ながら、あまりにも新しい機能は解説できていません。 不変的な情報に絞って解説しています。 現在開発中のunite.vim Ver.3.0について少しだけ触れています。

もちろん、Emacsの人達にもオススメ

EmacsテクニックバイブルがVimmerにも有用な本であったように、 当然VimテクニックバイブルはEmacsを使っている方々にもオススメです。 Emacsを使っている人も、異文化交流は重要です。 同じ環境で満足していたら、何も生まれません。 auto-complete.elもVimの補完機能を参考にしています。 つまり、Emacs使いであってもVimや他のエディタからも刺激を受けるべきなのです。 この本を読めば、最近のVimの機能やプラグインについて分かります。 例えば、unite.vimとanything.elの違いが分かります。 新人にVimを教えざるをえないときにも使えます。 さらに、一身上の理由により、Vimに乗り換えざるをえないときもVimテクニックバイブルの知識があれば安心ですね。

現在確定している情報

ページ数は384Pで、Emacsテクニックバイブルと同じです。 値段は￥2, 980+税です。基本的に技術書というのは、￥3000を越えると購入までのハードルが上がってしまいます。 ページをできるだけ減らしたこともあり、税抜きでなんとか￥3000は切ったのですが、若干Emacsテクニックバイブルより高くなってしまいました。 発売日は9月中旬予定ですが、詳しい日付けの確定はしていません。 目次については、八月中に確定する予定なので、九月には詳しい情報が出せるでしょう。 まだ発売まで時間があるので、しばらくお待ちください。

残念ながら載せられなかった内容

できるだけ、著名なプラグインは載せるように心がけましたが、 ページ数の都合やその他様々な理由により載せられなかったプラグインがあります。 ここではそれらについて紹介します。

VCSとの連携

VCSと連携できるプラグインとしては、git-vimやfugitive.vimがありますが、決定版と呼べるようなものがなかったためです。 vcs.vimが候補だったんですが、未完成でした。

shadow.vim

時間とページ数の都合が付きませんでした。

snipMate

neocomplcacheのスニペット機能で十分だったためです。解説する人もいませんでした。 ちなみに、snippetsEmuはページ数が足りませんでした。

echodoc

入れてもよかったんですが、他のTipsが削られすぎて入れる暇がありませんでした。

netrwについての詳しい解説

時間とページ数の都合がつきませんでした。 ただし、一部のTipsでnetrwの機能について触れられています。

metarw

使っている人があまりに少ないため削られました。metarwがやっていることは、vimfiler+unite.vimでできるようになる予定です。

vimprocの使い方について

書籍では簡単にvimprocについて触れていますが、さすがに詳しい解説はできませんでした。 想定読者にとっては難しすぎるからです。vimprocをバリバリ使えるような層では、Vim scriptから使い方を解読するのも簡単だと思います。

vital.vim

このプラグインは、プラグイン制作者のためのものです。この本の対象読者にはレベルが高すぎました。 それに、ページ数の余裕もありませんでした。

内容の陳腐化への懸念について

書籍は生物です。コンピュータに関する書籍は出たばかりのときに購入しておかないと、役に立つ前に時代遅れとなってしまうでしょう。 だからこの本が必要なら、発売されたらすぐに購入するのが適切です。特に、一度絶版になってしまったら取り返しがつきません。 本の売り上げが上がると、出版社に対するVimへの印象が良くなり、続編などが企画されるかもしれません:-)

特に私のプラグインは進化が早いため、本が出たらすぐに時代遅れとならないか心配してくれている人がいるようです。 はい。それは正しい指摘です。 ただ、私もそのことは分かっていました。だからわざと新しすぎる機能や、あまり使われない機能については本の中では解説せず、 「適時:helpを参照してください」ということになっています。できるだけ不変であろうことについて解説するようにしています。 それでも現在の実装と齟齬がでてきてしまった場合は、正誤表にて何かしらのフォローをする予定です。

「:helpに全部書いてあるから書籍は必要ない」という意見について

これはある意味事実です。だからこそ、本の対象とする読者は「Vimの基本的な操作や設定はできるが、:helpを自在に引くことはできない層」なのです。 :helpはリファレンスマニュアル的であり、分からない語句を検索するときに使います。 初心者が通読するには向いていません。 本というのは初心者が参照しやすいように、重要な情報をふるい分けることに価値があると考えています。

ただし、私が自分の記事の中で気をつけたのは、できるだけ「設計思想や使い方について解説をする」ことです。 これは:helpに書いていないことが多いうえに、内容が陳腐化することも少ないと考えました。 だから、ヘルプを自由自在に参照することができる、レベルが高いVim使いにとっても役立つ書籍だとは思います。 これが本当かどうかは、自分の目で本を見て確認してください。

なぜ「Vimテクニックバイブル」はVim scriptを学ぶ本ではないのか

それは需要がないからです。考えてみてください。あなたの周囲にVim scriptをバリバリ書けるような人はいますか？ Vimが好きだから、Vim scriptを本格的に学びたいと考えている人はいますか？ まずいないでしょう。「Vimテクニックバイブル」の内容ですら出版社からはリスクがあると考えられている現状において、 日本でVim scriptを学ぶための書籍が出る確率は0です。おそらく売れません。 「Vimテクニックバイブル」にはVim scriptの解説がある程度書いてあります。 しかし、一流のVim scripterになるための道はまだまだ険しいのです。

それでもVim script本の構想を諦めきれない場合は、まず「Vimテクニックバイブル」を購入し、その本に書いてあることを全てマスターしてください。 さらに「Vimテクニックバイブル」を周囲に宣伝し、全国のVimmerのVimレベルを上昇させてください。 その暁には、Vim script本の出版リスクは低減され、いつの日か発売されるかもしれません。

オマケ

今後、vim-users.jpで「Vimテクニックバイブル」に関する何かが掲載されるかもしれません。こうご期待！ ちなみに、Vimテクニックバイブルを購入してもらった場合、勉強会でShougoのサインが貰えるかもしれませんよ！

Shougo

あるファイルを編集中に全く関係のない別の作業をすると、カーソルの位置を見失ってしまうことが多々あります。
そんな場合に少しでも見失い難くするために、カーソル位置を目立たせることが有用です。

‘cursorline’ と ‘cursorcolumn’ を設定することで、現在のカーソル位置をハイライトすることが出来ます。

:set cursorline
:set cursorcolumn

それぞれ、以下の様にすることで、highlight の指定が行なえます。

:highlight CursorLine     xxx term=underline cterm=underline guibg=Grey90
:highlight CursorColumn   xxx term=reverse ctermbg=7 guibg=Grey90

参照資料

• :help cursorline
• :help cursorcolumn
• :help hl-Cursorline
• :help hl-CursorColumn

Sixeight

問題

MacVimをお使いの方に捧げる記事です。

MacVimをはじめとするGUIのVimの特徴の一つとして、半透明具合をVimから操作できるという点があります。

MacVimの場合、半透明具合は'transparency'で調整できます。0が不透明、100が完全に透明です。例えば20%の透明具合にするには、

:set transparency=20

とします。これは

:let &transparency = 20

としても同様の結果が得られます。現在の透明度の値を得たければ、変数&transparencyを参照してください。

MacVimにおける半透明処理はまだExperimentalで、Preferencesから以下のような設定を行う必要があります。

まだExperimentalと主張していることからわかるように、半透明処理には既知のバグがあります。不特定のタイミングで、画面の一部が不透明になり、だんだんと不透明部分が全体に浸食していきます。

見てのとおり、かなり深刻な問題かつ数多くのユーザに確認されつつも、この問題は数年間に渡り解決されないまま今に至っております。

対処

実は、オプション値'transparency'がいつのまにか勝手に書き変わっています。これを再び書き換えて<C-l>を打鍵するだけで、うまく再描画されます。

:set transparency=10

ただ、それ描画が狂う時点の前にどんな'transparency'を設定していたかその具体的な忘れている場合がほとんどでしょう。普段からset transparencyするときに常に同時にg:transparencyなどの変数にその値を格納しておき、そしてその値に戻ることができるようにKey mappingを設定するのがよいでしょう。

例として、筆者は半透明度の変更と、半透明再描画をそれぞれ以下のように割り当てています。すべて、~/.vimrcではなく~/.gvimrcです。

• より透明にする: ↑

    nnoremap <up> :<C-u>call <SID>relative_tranparency(5)<Cr>
    inoremap <up> <C-o>:call <SID>relative_tranparency(5)<Cr>
  

• より不透明にする: ↓

    nnoremap <down> :<C-u>call <SID>relative_tranparency(-5)<Cr>
    inoremap <down> <C-o>:call <SID>relative_tranparency(-5)<Cr>
  

• 再描画: <esc><esc

    nnoremap <Esc><Esc> :<C-u>let &transparency = g:transparency<Cr><C-l>
  

ただし以下の関数を同じファイル内で定義しておくものとします。

function! s:relative_tranparency(diff)
  let &transparency = a:diff + &transparency
  let g:transparency = &transparency
endfunction

補足

筆者はもともと<esc><esc>に:set nohlsearchの副作用を持たせるkey mappingをしていました。これを組み合わせため、筆者の設定は以下のようになっています。

    nnoremap <Esc><Esc> :<C-u>set nohlsearch<Cr>:let &transparency = g:transparency<Cr><C-l>

ujihisa

コマンドラインに何か赤いハイライトで出力されたけど 見えなくなってしまった場合、:messagesあるいは 短縮形である:mesと入力すれば見ることができます。 しかしそのエラーを何か別の場所(twitter,gist,…)に コピペするにはどうすればいいのでしょうか？

解決策1: gvimでマウスで選択し<C-y>を使う

gvimでのみ使える技です。

:mesと入力したあと、 図のようにマウスで選択して<C-y>を押します。

解決策2: :redir > {file}を使う

gvimでも端末版vimでも使えます。

:redirというExコマンドを使うと、 Exコマンドの出力をキャプチャーし、 ファイルや変数に保存できます。

:redir > messages
:silent messages
:redir END

これでmessagesというファイルに出力結果が保存されます。 :silentはつけると:messagesの出力をコマンドラインに出力しません。 つけなくてもファイルの中身に変わりはありませんが、 今回はコマンドラインに出力されてもうっとうしいだけなので付けただけです。

tyru

Vim の中で Git を快適に使うためのプラグインがいつくかあります。 その中から Time Pope さん作の Fugitive.vim を紹介します。

motemen さんの git.vim については Hack #67: Gitを使う を参照してください。 今回の記事は対比のためフォーマットを似せています。

インストール

plugin は github から入手可能です。 https://github.com/tpope/vim-fugitive

また Vundle でもインストール可能です。

:BundleInstall tpope/vim-fugitive

使い方

以下のコマンドが定義されます。

• Git arg: git コマンドと同様の機能を有し、自分で定義した alias も使用出来ます。

Git コマンドを使用した場合は結果を pager に表示します。 以下のコマンドを使用すると結果は状況に応じてバッファ内、quickfix list 等に表示されます。 また、diff を vimdiff で表示したり、blame もハイライトされた状態で表示されたりと、それだけでも利用価値があると筆者は考えます。

• :Gdiff[ rev]: git diff[ --cached] {編集中のファイル}
• :Gstatus: git status
• :GlLog[ rev]: git log {編集中のファイル}
• :Gwrite: git add {編集中のファイル}
• :Gread[ rev]: git checkout {編集中のファイル}
• :Gcommit: staged なファイルがあれば git commit なければ git status
• :Gblame[ rev]: git blame {編集中のファイル}

上記以外にも Git を扱ううえで有用なコマンドが多数定義されます。:help fugitive を参照してください。

Gstatus 時の挙動について

:Gstatus を使用すると、Window が split され git status の結果が表示されます。

定義されたいくつかの mapping を利用することで、更に便利になります。

• : カーソル下にあるファイルを edit
• -: カーソル下にあるファイルを git add
• p: カーソル下にあるファイルを git add -p
• D: カーソル下にあるファイルを git diff[ --cached]
• C: git commit

応用

筆者は以下のように mapping して利用しています。

" for Fugitive {{{
nnoremap <Space>gd :<C-u>Gdiff<Enter>
nnoremap <Space>gs :<C-u>Gstatus<Enter>
nnoremap <Space>gl :<C-u>Glog<Enter>
nnoremap <Space>ga :<C-u>Gwrite<Enter>
nnoremap <Space>gc :<C-u>Gcommit<Enter>
nnoremap <Space>gC :<C-u>Git commit --amend<Enter>
nnoremap <Space>gb :<C-u>Gblame<Enter>
" }}}

参照資料

• tpope/vim-fugitive

Sixeight

表示幅に入りきらないコードは読む人に必要以上にストレスを与えます。
プログラミングの70割は読む時間だといいます。
読む人にストレスを与えないよう、
横幅が長いコードを書かないようにするにはどうすればいいでしょうか？

解決

Vim 7.3 *1 では 以下を.vimrcに入れると80文字以上長い列をハイライトしてくれます。

set textwidth=80
if exists('&colorcolumn')
    set colorcolumn=+1
endif

どのファイルに対してもハイライトされてしまうため多少うっとうしいです。
この問題は.vimrcで'textwidth'を0に指定しておき、
コードを書く時のみ:setlocal textwidth=80とすることで回避できます。

set textwidth=0
if exists('&colorcolumn')
    set colorcolumn=+1
    " sh,cpp,perl,vim,...の部分は自分が使う
    " プログラミング言語のfiletypeに合わせてください
    autocmd FileType sh,cpp,perl,vim,ruby,python,haskell,scheme setlocal textwidth=80
endif

• *1 7.3.175以上推奨 (:setlocal cc=+1しても:newした後ハイライトが残るバグがあるため)

tyru