Vim に関するメモ書き
Vimscript の題材(2012.07.14)
Vim script に手を付けようと手頃なプロジェクトを探していたのだが、身近な skk.vim を見ることにした。quickrun とかは開発中で freeze してないしね。前から気になっていた「辞書データをどのように持っているのか？」を知りたくなったというのもある。
開いてみたものの良くわからないので、skk.el を見てみることにした。おい！辞書ファイルをあるデータ型に変換して保持しているわけではなく、裏バッファで開いておき、それに検索をかけて対応する単語を表示しているみたい(やっぱり)。
自分は外部ファイルを開いて一行ずつ読み込んで split して配列に追加していくという方法を多用するのだけど、Emacs Lisp ではこの「一行ずつ読み込む」に相当する部分がわからなかった。だから裏でバッファを開いてその中で検索置換を繰り返し、連想リスト状態になった所で eval して値に束縛させるという方法を取った。
buffer-substring-no-properties という関数があって、これはポイントで挾まれた部分を文字列として(コピーして)取り出せるというもの。これを利用すれば「一行ずつ読み込む」ことが出来そう。取り出した文字列に対して split-string で分割してやればリストとして使える。ポイントをどうやって得ているのかは必要になったら見よう。
どうも連想リストを使っているわけではなく、変換毎に「読み」を検索して、その対応する行に移動しては上記の作業を行なって、候補一覧を作っているみたい。SKK は昔からあるものなので、データ型に依存しない形を選んだのかな。それとも変換にかかるコストを鑑みた？
それにしてもコメントが日本語で書いてあるので、英語の読めない後学の者にとってはとても助かるものとなっている。これは見習うべきところ。
おっと、Vim script に戻る。skk.vim では一番最後(4300行くらい)に「Vim 7 系をお使いの皆様へ」ということで、データをリストで保持している旨が書かれている。この際、文字コードや改行コードについての情報も持たせているそうだ。なるほど。
exe なんてコマンドを使ってる...。何だろうこれ？あ、execute の略か。add じゃなくて insert を使ってる。リストと言っても配列型の変数を使うというわけではなく、リストの形をしたファイルで保持するのか。どうしてだろう？単語の追加や削除に弱いってことなんだろうか？
検索には線形と二分を併用しているみたい。ということは、辞書はソートされてないとダメなのか。コンプサーチって何だろう？読み慣れていないので追うのが辛い。complete じゃなくて compare なのかな？
スクリプトを読むのに(辛くて)飽きた。Wikipedia で探索について調べてみるかなぁ...。そしてこの話題には戻ってこなくなるのだった...。
MinGW 版で Perl モジュールを使えるようになった(2012.07.03)
しばらく挑戦を続けている if_perl を有効にしてビルドする件。もうちょっと詳しく書くと、下記のようなエラーが出るのだった。
undefined reference to `_perl_buf_free`
collect2.exe: error: ld returned 1 exit status
リンクエラーということらしい。各種オブジェクトファイルはコンパイルできているのに、最後のリンクができずにバイナリが出来ないという話。ソースを grep してもそれらしいものが見付からない。もしかして perl 側の header を見ないとダメなのかな？
しまった、「_perl_buf_free」で検索しちゃダメなんだ。最初のアンダーバーは付けちゃいけない。if_perl.c だけは auto 以下に作成されるので、これを開いてみる。iBook で使っていたソースをそのままコピーしたやつだから、Mac 用の if_perl.c が生成されてるのかな？
日付を見ると古いままだ。確かこれは configure スクリプトが作成していたのだったかな？MinGW では Make_ming.mak を指定して make するだけなので、ここに問題がありそう。まずは if_perl.c をリネームして make を実行してみる。clean が上手く動かないので手動にて src/obj/ 以下を削除してからね。
何も変わらない...。auto/ 以下でなく、src/ 以下に空の if_perl.c ファイルが存在していた。これを削除してからもういちどやり直してみよう。
今度は ParseXS が動かなくて if_perl.c を生成できないよ〜ときたもんだ。@INC って何だろう。あれか、msys の方の perl を動かしちゃってるのかな？パスの順番は苺パールの方を優先にしてあるんだけど、それじゃダメってことか。xsubpp というプログラムも動かすみたいだし...。
MinGW (msys) の perl.exe と xsubpp をリネームして使えないようにしてから再度挑戦だ。お〜！src/ 以下にちゃんとした大きさの if_perl.c が生成されていた。最終的な Vim のバイナリもできてる！
:perl VIM::Msg("homu")
で「homu」が出力されて終了。やったね。
MinGW 版 Vim のモジュールを有効にする(2012.07.02)
Vim の本体をビルドできるようになったので、拡張モジュールを使えるようにする。Ruby のバージョンは 1.9.3 なのだが、指定するときは 1.9.1 としなければならない。具体的には下記。
mingw32-make -f Make_ming.mak WINVER=0x500 GUI=no MBYTE=yes ICONV=yes \
RUBY=C:/opt/Ruby193 RUBY_VER=191 RUBY_VER_LONG=1.9.1 DYNAMIC_RUBY=yes
Python を有効にする場合は下記を追記する。
PYTHON3=C:/opt/Python32 PYTHON3_VER=32 DYNAMIC_PYTHON3=yes
ビルドは出来るのだけど、実際に使うと runtime error という(Python側の)エラーになっちゃうのが...。レジストリエディタでパスの整理をしたら動くようになった。何度もインストールし直してるからなぁ。ものすごく...きたないです。
Lua を有効にする場合は下記を追記する。
LUA=C:/opt/Lua/5.1 LUA_VER=51 DYNAMIC_LUA=yes
Perl はビルドできませんっ。
MinGW でのビルドができた(2012.07.01)
vim_dev にあった
mingw32-make -f Make_ming.mak WINVER=0x500 GUI=no ...
でビルドすることができた。たぶんそのうちパッチが出ると思う。よかった。
そういえば、動作確認で自作スクリプトを動かしたのだけど、Mac と Win では色の設定が違うのね。ターミナルの違いかもしれないけど。Win では DarkMagenta が暗すぎて判別できないので Dark を取った。
MinGW でのビルドは難しい(2012.06.30)
7.3.582 へアップデート。パッチラッシュが終ったようなので 581 まであてる。Mac ではビルドが完了するものの test 68 でエラーが出てしまった。これは patch 576 の変更で問題が出たみたいで、vim_dev でフォローされていた(patch 582 が出て問題が解消した)。
Win の方は「MEMORYSTATUSEX 知らね」というエラーになってしまった。こちらは patch 577 での変更が原因みたい。一度にたくさんパッチをするとどれが原因なのか調べるのが辛い。
[msdn.microsoft.com/en-us/library/aa366589.aspx] によると
Minimum supported client: Windows XP
となっているのでサポートはされているみたい。mingw に無いのかな？/include/w32api/winbase.h で typedef されとるな。include されてないとか？
#include <w32api/winbase.h> を os_win32.c に追記してみたけど、そんなファイル知らんと言われた。MinGW/include と MinGW/msys/1.0/include のふたつあるのだけど、どちらを見てるのかな？ msys-sh で cd /include をすると後者の方に移動するんだけど。
hoge.h を片方ずつに置いて実験をしてみると、どうやら MinGW/include の方しか見ていないみたい。っとっとっと。MinGW/include/winbase.h が存在してる。こちらでも typedef されてる。if (_WIN32_WINNT >= 0x500) とかいう条件で囲われているから、この条件ではじかれてるのかもしれない。
これをはずしてみると os_win32.o が生成されるけど、最終的にアゥアゥ。
undefined reference to `_GlobalMemoryStatusEX`
collect2.exe: error: ld returned 1 exit status
てな具合。やっぱりヘッダファイルをいじるのは良くない。
mintty でハマる(2012.06.28)
Vim を mingw でコンパイルしようとするもうまくいかない。LUA を disable にしようと Make_ming.mak を見ていたら、ifeq else endif を使っている部分を発見した。例の mruby で問題が出ている部分ね。Vim は古い環境のサポートも面倒見が良いので、旧式の書式で書いてくれているのかな。
話は戻って、Windows には Lua を入れていないのでヘッダファイルがない。無効にしようにもコマンドラインからのオプションでは制御できないようで、LUA=no としても if_lua を作成しようとしてエラーになってしまうのだった。というかデフォルトでは on なのね。
良くわからないので Makefile にある LUA 関係をすべてコメントアウトしてビルド。
mingw32-make -f Make_ming.mak GUI=no MBYTE=yes ICONV=yes
という簡潔なオプション設定にした。
おろろ？perl と python 関係でもエラーになっちゃう。軒並コメントアウトしてビルドのし直し。ようやくバイナリの完成を見た。
どうして素直に kaoriya 版を使わないのかというと、mintty から vim を起動できないからなのだった(gvim は動く)。ということで先程ビルドした自作のやつを起動しよう。
あれ？起動しない。どういうことだろう？mingw に附属している Vim は起動するというのに...。仕組みはわからないけど、Terminal 内で別のプログラム(screen)を開けない感じ。自作のシェルスクリプトも引数の扱いが変だし...。
コマンドプロンプトの cmd.exe からはどちらも動くので、バイナリに問題があるわけではなさそう。mintty の設定に問題がありかも。
続き。 Vim がビルドできないのは .bashrc にパスを設定しているからかもしれない。ということで export している部分をコメントアウト。実は昔に入れていたアプリケーションへのパスを削除していなかったのでした。とほほ。
これで make をしてみると、確かに各種オプションがオフになっており、MBYTE や ICONV などのオプションしか有効にならなかった。環境変数名を同じにしてしまっていたのもいけなかったんだね(Ruby は RUBY193 にしていたので大丈夫だったのだ)。やっても〜た〜。
Vim を普通にビルドすることに成功したけど、mintty から起動できない点は解決していない。vim --version までは動く。vim -u NONE はダメ。ネット上をうろついてみると、やっぱり「mintty + 野良 Vim」の組み合わせは動かないみたい。では msys-vim が動いているのはどうしてだろう？特別なパッチでもあててあるのだろうか？
タイマー(2012.06.26)
reltime() で現在時刻を取得できるそうなのでタイマーが作れそう。変換の前に「let start = reltime()」として開始時の時刻を保存しておく。これは関数ローカル変数になるので頭文字を付けなくてよい。substitute 処理の後に「reltimestr(reltime(start))」とすれば、終了時との時差が表示される。
手元のストップウォッチと比べてもそれほど差がないので、使い方としてはこれで大丈夫みたい。普通に考えると、stop のような時刻も取得して、その差分を得るような形になるのかと思うのだけど、reltimestr を呼んだ時点で stop の時刻が自動的に得られていると考えればいいのかな。
やっぱり Python はダメだった(2012.06.19)
Perl もちゃんと動くようになったので、Python3 も動くようにしたい。Ruby や Perl と同じように --with-threads --enable-shared オプションを付けて、Python3 をビルドし直した。
そして Vim で --enable-python3interp=yes を付けて configure を実行するのだけど、
checking --enable-python3interp argument... yes
checking for python3... /usr/local/bin/python3
checking Python version... 3.2
checking Python's abiflags... m
checking Python's install prefix... /usr/local
checking Python's execution prefix... /usr/local
checking Python's configuration directory... (cached) /usr/local/lib/python3.2/config-3.2m
checking if -pthread should be used... no
checking if compile and link flags for Python 3 are sane... no: PYTHON3 DISABLED
のような表示がされてしまう。「-pthread should be used」って何だろう？Python 側 には -pthread というオプションは無いんだけど。
src/auto/configure で探してみる。Python3 に関するものは 5665 行目から。uname でシステムのことについて調べてるのか。"(uname) 2>/dev/null" != Darwin; でいきなり if の外に出されちゃってる。他のシステムだと threadsafe_flag="-pthread" とかになるみたい。でもこれが原因だとすると、すべての MacOSX 上では if_python3 が使えないことになる。他に原因があるのだろう。
5725 行目からも関係がありそう。ここで DISABLED になると今まで設定した LIBS とかがクリアされちゃうんだよね。ac_fn_c_try_link って何だろう？1653 行目から関数みたいな感じで書かれている。
if ac_fn_c_try_link "$LINENO"; then :
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
$as_echo "yes" >&6; }; python3_ok=yes
else
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no: PYTHON3 DISABLED" >&5
$as_echo "no: PYTHON3 DISABLED" >&6; }; python3_ok=no
fi
型とか無いからプロトタイプって訳でもなさそうだし、何やってるんだろう？しまった、シェルスクリプトか。これはわからん。
新 skk.vim に添付されているヘルプを見てビックリ(2012.03.16)
skk.vim。Last Change: 11-Oct-2006 の skk.vim を使っているのだけど、ちょっとした気の迷いで vim.org から 2011-03-11 版をダウンロードして使うことにした。気の迷いといってもヘルプが無かったのが理由なんだけどさ。スクリプト単体でしか保存してなかったんだね自分。
せっかくなので eskk にしようと思ったけれど、インストールマニュアルが無いのと、vital 事件の影響で素人の私には不安定というイメージが植え付けられているのでした。OS が不安定じゃその上で動くアプリケーションを安心して使えないじゃん？という発想。Windows でいえばどの程度のバージョンになるのだろうか？3.1？
というわけで、~/.vim に放り込んで :helptags /path/to/skkd/doc でタグを作成して :help skk を実行。vim-jp でお馴染みの名前に二礼二拍一礼してからつつつ〜っとスクロール。おや？目次の次にコンテンツが......ねぇ〜〜〜っ！くそがあ〜〜〜ぁ。
どうも
fdm=marker:fmr={{{,}}}
が怪しいなぁ。なるほど、org-mode や outline-mode のように折畳みが出来るのね。余計な真似を...
Terminal 版でのコピー＆ペースト(2012.03.14)
pbcopy は使っていたけど pbpaste は盲点だった。こりゃいい。さっそく .vimrc に登録しよう。コピーは ;y だったからペーストは ;p とでもするかな。いやまぁ、インサートモードにしてターミナル機能の cmd-v でもいいんだけどさ。
set clipboard+=unnamed,autoselect
function! MacRegionCopy() range
execute ":silent '<,'>w !nkf -Ws|pbcopy"
endfunction
vnoremap <silent> ;y :call MacRegionCopy()<CR>
function! MacClipPaste()
execute ":r !pbpaste"
endfunction
noremap <silent> ;p :call MacClipPaste()<CR>
Vim の置換が Emacs よりも遅い理由(2012.03.13)
mattn さんのつぶやきを参考に log を取って(set verbosefile) mto を動かしてみたら、裏で
Error detected while processing function MtoReplaceKanaTrad..ReplaceString:
line 3:
E486: Pattern not found: 会い
...
上記が 1000 回くらい繰り返されるのだ
が大量に出ていた。検索でマッチしないものはエラーで出力してたのね。silent! にしてたからわからんかった。これが Vim が Emacs よりも遅い原因なのかもね。つぶやき見てると勉強になるね。それにしてもパッチ投げたり、おっぱいだったり、ちんちんだったり、ちょこまか動いてフットワークが軽いけど、パソコンの専門家なのかしらね。かなり詳しい。
あと、キーリピートを最速にしたら Vim や Emacs のレスポンスが良くなった。なぜいままで気付かなかったのだ。
置換された単語を色付けするようにしたけど、置換を切り替える度に match none で前の結果を消さないとダメなんだろうか。ほとんど使っていない check_kana を動かすと前の match が無効になるので、結果的に色付けを解除できてしまうという状態。完璧じゃなくていいんだ。それでいいんだ。
Windows の Vim で SBCL を使う(2012.01.22)
quickrun で手軽に markdown を確認できるようになったのが嬉しくて、他のスクリプトもあれこれと実行させて遊んでいた。すると、月齢を計算する lisp が動かないことがわかった。正確には Mac では動いて Windows では動かなかったのだ。当初は「パスの設定かなぁ」と思っていたのだけどそうではなかった。
実は Mac では clisp 、Windows では SBCL をインストールしているのでした。quickrun.vim には Lisp の実行プログラムとしては clisp のみが設定されているので、Windows ではエラーになってしまったわけ。
先日と同じように .vimrc に記述すれば良いのだけれど、良い機会なので下記のように少し修正してみた。辞書型データの中がネストしていてこんがらがる。
\ 'lisp': {
\ 'type': executable('clisp') ? 'lisp/clisp':
\ executable('sbcl') ? 'lisp/sbcl': '',
\ },
\ 'lisp/clisp': {
\ 'command': 'clisp',
\ },
\ 'lisp/sbcl': {
\ 'command': 'sbcl',
\ 'cmdopt': '--script',
\ },
だたし他の例を見てみると、cmdopt で書いている部分は
\ 'exec': '%c --script %s',
のようになっているものが多い。どちらにしても動くのだけれど、違いについてはよくわからない。引数を渡す場合と渡す必要がない場合の違いかなぁ。先日 .vimrc で設定した markdown 用の設定も
\ 'cmdopt': '-Ku c:\Ruby193\bin\kramdown'
=> \ 'exec': '%c -Ku c:\Ruby193\bin\kramdown %s',
にした方が良いのだろうか？
月齢スクリプトを Vim で開いてさらに気が付いたこと。Windows の Kaoriya-Vim で ruby スクリプトを開くと、
行 76：
NoMethodError: undefined method `add' for "C:/Ruby193/lib/ruby/gems/1.9.1":String
行 93:
E121: 未定義の変数です: s:ruby_path
E15: 無効な式です: s:ruby_path
のようなエラーが表示される。Mac の野良ビルド Vim では発生しない。どちらも ftplugin/ruby.vim は「Last Change: 2010 Mar 15」となっている。違いはビルドオプションにあって、Mac では -rubyinterp になっている。これは Mac だと「dyld: vim Undefined symbols: _rb_encdb_declare」というターミナルをも巻き込むエラーが生じてしまうために off にしてあるのだ。
75 行目から見てみると、+ruby で win32 だと以下の ruby VIM ... が実行されて上記のエラーが発生するみたい。
elseif has("ruby") && has("win32")
ruby VIM::command( 'let s:ruby_path = "%s"' % ($: + begin; require %q{rubygems}; Gem.all_load_paths.sort.uniq; rescue LoadError; []; end).join(%q{,}) )
let s:ruby_path = '.,' . substitute(s:ruby_path, '¥%(^¥|,¥)¥.¥%(,¥|$¥)', ',,', '')
プロジェクトページ から転送されて ここ にある ruby.vim と入れ替えるとエラーは発生しなくなった。この部分を比べてみると変更(修正が入っている)になっているみたい。
追記：大切なお話。これに目を通してください。上記で紹介している ruby.vim と本家の ruby.vim では動作に違いがあるそうです。(2012.04.22)
ftplugin とかは vim.org 本家そのままのものが収録されていると思うけど、他の人はエラーにならないのだろうか？またしても「マイ環境の問題」ってやつかしら？それとも、Windows + Vim + Ruby で使う人が居ない？
QuickRun のソースを参考にして新規ウインドウを開く(2012.01.18)
テンポラリバッファのことを Vim では 一時ファイルと表現しているみたい。検索する時になかなかヒットしなかった。ファイルなのかバッファなのかの違いもあるけど。
一時ファイルの作成(nanasi.jpより)
:edit `=tempname()`help の autocmd 節
FilterReadPre, FilterReadPost フィルタの出力による一時ファイルを読み込む
「現在のバッファの名前に対してパターンを調べる」が何を意味しているのか不明だけれど、あれこれ実験してみる。
やりたいことは
現在のバッファ全体もしくは選択した文字列に対して
:!python3 mto.py tradkana %
で処理した結果を分割したウインドウのテンポラリバッファで開き、確認後は「q」で閉じる
というもの。とりあえずサンプルファイルを開いて上記コマンドを実行する。こうすると一旦シェルに戻って変換された文字列が表示され、最下部に
Press ENTER or type command to continue
と出てくる。いつもは RETURN を押して戻っていたけれど、良く見てみるとコマンドも打てるみたい。ここでどんなコマンドを打てば良いのだろう？
:ls
とすると開いているファイルリストが表示されるので、EX コマンドが使えるってことだね。どうも autocmd は関係ないみたいだなぁ。
先日の「Vim で markdown をプレビューする計画」は失敗に終ってしまったのだが、転んでもタダでは起きないわけで、何かしら得るものがあった。Vim Hack #230 の解説によると「outputter を browser にせよ」と書いてあった。外部プログラムで処理した内容の表示場所(つまり出力先)を変更できるということだね。
検索すべき単語もディレクトリ構成もわからないので手の付けようのなかった QuickRun のソース。出力を制御する処理はここにあり。なんだか手掛かりが見付かった感触。
~/.vim/plugin/quickrun/autoload/quickrun/outputter/buffer.vim を眺める。内容を見ても理解できないので「読む」とは言えない状態なり。
'split': '%{winwidth(0) * 2 < winheight(0) * 5 ? "" : "vertical"}',
たぶんこれは縱分割にするか横分割にするかの判定場所だと思うのだけど、if 文じゃないから違うのかな(はてブロでJavaScriptが使えるってことで調べてたら似たようなものを発見した。条件演算子ってやつかも)。winheight(0) の値って、ターミナルの高さ -2 になるのね。自分は「set laststatus=2」にしているからかな。
本丸ちっくな場所を発見！
function! s:open_result_window(sp) " 変数 sp はどこで求めてる？何？
...
if !bufexists(s:bufnr)
execute a:sp 'split' " とにかく分割
edit `='[quickrun output]'` " テンポラリバッファを作成
let s:bufnr = bufnr('%') " (その作成した)バッファの番号
nnoremap <buffer> q <C-w>c " 「q」だけで閉じることができるように
setlocal bufhidden=hide buftype=nofile noswapfile nobuflisted
setlocal filetype=quickrun
...
endfunction
わからない事だらけ。「vim nnoremap
autocmd FileType help nnoremap <buffer> q <C-w>c
のように良く使われる手法みたい。とにかく「q」だけで閉じることができる一時ファイルを作成できそう。あとは外部ファイルで処理した内容を読み込む部分だね。「silent % delete _」とか「silent $ put = data」とかあたりかな？
ダメだ〜、閉じる時に確認されちゃう(-_-;)。続く setlocal の部分も重要だったのか。これを記述したら「q」で有無を言わせず閉じるようになった。残りの問題は、連続でコマンドを実行すると同じバッファに追記されていっちゃうこと。tempname() を使えば 26 回までは確実に別のバッファ名になるそうなので、こっちを使おう。
よし、これを関数にして、今まで new で新規バッファを作成していた部分と置き換えればウマーになるかな？
でけたでけた。でも... Pure Vim script を作成してからは外部プログラムを利用する変換をしなくなったので、意味がないような気がする...。いつか別のプロジェクトで使うかもしれないじゃないか！無駄なことなんてないよ。
些細なことかもしれないけど、使用するコマンド決定の部分は
type Markdwon.pl
kramdown
bluecloth
redocarpet
pandoc
の順番になっているのに、コマンドの詳細設定の部分は
command Markdwon.pl
bluecloth
kramdown
redocarpet
pandoc
のようになっている。これ、らしくないけど何か理由があるのかな。アルファベットの順番？
理由もなく実行(2012.01.11)
:so $VIMRUNTIME/bugreport.vim
を実行する。
Vim-jp のマニュアルを HTML 化する練習(結局出来ませんでした)(2011.12.28)
GitHub の Wiki にある作業手順に従って html ファイルの更新を試みる。master は clone してあり、いつも pull チェックをしているので以下のコマンドから実行する。Git は add, commit, pull, push, diff, log しか使ったことが無いので、初めて使うコマンドになる。ちなみにこれを実行する前のカレントディレクトリの中身は
doc/ syntax/
のようになっていた。
作業領域の切り替え
git branch -t devel origin/devel
git branch -t gh-pages origin/gh-pages
git checkout devel
こうすると、カレントディレクトリの中身が
Makefile doc/ en/ html/ tools/ tutor/ vim_faq/
のようになった。doc/ の中には .jax ファイルは存在していない。en/ の中には英語の原文である .txt ファイルが収納されている。html/ の中には *.html の他に devel/ と master/ ディレクトリが存在し、さらに詳しく見てみると、
devel/ 以下には Makefile en/ tools/ tutor/ vim_faq/
master/ 以下には doc/ syntax/
という具合になっている。見せ方が違うだけで、ファイルやディレクトリは決まったものが含まれているようだ。解説等で良く見掛ける「作業領域が切り替わる」というのはこの現象のことを言っていたんだね。私のマシンはとても遅いのだけれど、それにもかかわらずブランチの切り替え動作は速い。全くストレスにならない。これは凄い。
自動処理
続いて html の作成(更新)
git checkout devel
vim -u tools/buildhtml.vim
以下のエラーが表示されてしまったものの、しばらくすると処理がはじまった。
Error detected while processing /homu/vimdoc-ja/tools/buildhtml.vim:
line 14:
E480: No match: *
待つことおよそ 1 時間。127 ファイルを処理するのにこんなに時間が掛ってしまった。
実行中のスクリーンショット
プログレスバーが格好いい
あ、ありゃ？
きちんと処理はされているはず...
この現象は Terminal の再描画速度が遅い為に生じるので、最近のパソコンでは再現することが出来ないかもしれません。
ちなみにこの処理は変更されたファイルのみではなく、全てのファイルが対象となるので、毎回 1 時間掛ってしまう点に注意。ある意味で自動化処理なので、寝る前にコマンドを打っておけばオッケー。
ファイルの確認
html/ の中に入って
git diff HEAD^ | vim -
とするけれど、「& nbsp ;」ばかりでさっぱりわからないし、そもそもエラーが発生しているのでここから先の処理を続けるのは危険な感じ。
git checkout master
でいつもの場所(master)に戻ってみると、
doc/ html/ syntax/
となり、html/ ディレクトリが表示されたままになった。ここには先程作成した html ファイルが入っている。この状態で git pull しても Already up-to-date. と表示されて、引っ張ってくるだけなら問題はない。
Vim を使えば git の練習も出来ちゃうのである。
付録
作業中に出力されたメッセージ
Error detected while processing ~/.vim/plugin/quickrun/autoload/quickrun/outputter/browser.vim:
line 11:
E117: Unknown function: quickrun#outputter#file#new
E15: Invalid expression: quickrun#outputter#file#new()
line 13:
...
Press ENTER or type command to continue
これは QuickRun にブラウザを登録していない自分が悪い。
autocmd.jax.html: tag error: spell-SpellFileMissing
...
vim_faq.jax.html: tag error: 'ga'
タグのエラーだと？
