長い時間をかけてちくちくいじっていたものが終結しつつある。キーボード入力から vi コマンド / ex コマンドの実行、その実行の完了を保証するシーケンスポイントまでの一連の関数呼び出しが Promise の連鎖によって行われるように修正した。とても疲れた。

これにより、従来あんまり綺麗な形で実装していなかった非同期処理を、それを必要とする関数内に局所的に閉じ込める形にできて見通しが良くなった。例えばクラウドに対する読み書きの場合は、それを担当するのは ex コマンドのハンドラなのだが。応答が複数回来るので、一旦途中で ex 仮想マシンの実行を中断し、wasavi 側のグローバルなメッセージハンドラで受けて、適宜再開する…のようなことをしていた。バックエンドに対するメッセージは基本的に送信と応答の 1 回のやり取りで完結するので複数のやり取りに対応できないからだ。とても不自然。

これを、ex コマンドハンドラ内で Promise を生成し、新規に開いたメッセージポートを通して複数回のやり取りをし、すべてが完了したら resolve() するようになった。とても見通しがいい。

ex コマンドのエグゼキュータも Promise ベースで動作するように書き直した。疲れた。

マップマネージャもまた Promise を使用するように完全に書き直した。これもまた疲れた。

疲れすぎてもう海に還りたい。

そういうわけでちまちまといじっている。

とりあえず vi コマンドを回す部分に関しては修正した。これで非同期の処理だろうが同期の処理だろうが不自然なく呼べるようになった。それはいいのだが、vi コマンド群は本丸ではない。qeema が発生するキーボードイベントから、各 vi コマンドのハンドラに達するまで、せいぜい 4〜5 の関数がネストするだけであり、ただそれを Promise を使うようにすれば済む。

難しいのは ex コマンドの方なのだった。

ex コマンドは、ex コマンド列をコンパイルして中間コードの配列に落とし、それを逐一実行するという構造になっている。なので、修正するとしたら ex コマンドごとに Promise をつなげていく、ex コマンド自体はそれぞれ resolve() でコマンドの終了を通知するといった形になる。

ただいくつか面倒な点がある。

• write、read、edit などバックグラウンドに処理を投げるファイルシステム系のコマンドは、読み書きの進捗イベントをバックグラウンドから複数回返される。従来は、この複数回返されるメッセージというのは ex コマンドのハンドラの外で処理していた。というのも非同期的な ex コマンドを実行する際は一旦そのコマンドの同期的な部分のみを実行したあと executor を一時停止し、バックグラウンドから処理完了メッセージが到着したら executor.resume() で再開するようになっていたからだ。これは処理が分散しているといえばそうなので、若干不自然ではある。

  個々の ex コマンドを Promise によって駆動するのであれば、複数回返されるメッセージの扱いというものも ex コマンドのハンドラ内で完結できるわけで、そうすべきだと思う。具体的にはハンドラ内で long-lived connection をその都度行い、コマンド完了時に閉じればいい

• シグナルの扱い。シグナルというと若干語弊があるのだけど、つまりやはりファイルシステム系の時間がかかるコマンドの実行中、[cci]^C[/cci] が押されたらキャンセル扱いにする処理のことだ。これも Promise 化によって中身がかなり変わる。

ちなみに非同期で実行される ex コマンドとしては

• cd
• edit
• read
• c オプションが付加された s
• 非同期とマークされたオプションの値の変更を含んだ set
• write

となっている。また、レジスタを指定できる ex コマンドで [cci]*[/cci] レジスタが指定された場合も非同期になる。レジスタを指定できる ex コマンドは、

• delete
• put
• yank
• @
• *

となっている。非同期とマークされたオプションは以下のとおり。

• fullscreen
• syncsize
• columns
• lines

Migemo Server for Google Chrome™ というものがある。これ自体は migemo のライブラリのように動作し、外部の拡張からのリクエストを受け入れ、適切な結果を返す。

これに対応してみようかなとコードを頭の中で組み立ててみたのだけど、すぐに行き詰まってしまった。というのも拡張から拡張への通信というものは非同期に行われるからだ。一方で wasavi がキー入力を処理する構造は同期ベースで、非同期な動作を組み入れるのはとっても大変なのだ。

この辺を、Generator と Promise を組み合わせて使うようにすればとてもすっきり書けるのだが。なぜ今までそうしなかったかと言えばすなわち Presto Opera でも動かすためだ。Opera 12 は Promise の Polyfill は動くが、Generator は無理なのだ。

しかし、もう wasavi/0.6.657 で Presto Opera のサポートは終了した。従っていよいよそのへんを書き直す頃合いだ。これは割と大掛かりな仕事になるかもしれない。

wasavi の動作の保証として Selenium を用いた機能テストを通してからリリースしているわけだが、まとまった、自動化された形でのユニットテストは行っていなかった。これはけっこうイケてないので、ユニットテストの仕組みを構築したい。

そんなわけでいくつかのユニットテストコードを追加した。特に難しいことはなく
$ mocha src/unit-tests/strftime.js
などとする。

[cci]/[/cci] および [cci]?[/cci] コマンドには、デリミタに続けてオフセットを付加することができる。オフセットには符号を先行させてもよい。つまり
/foo/+
/foo/1
/foo/+1
はいずれも、カーソル行以降の foo を検索し、その次の行にカーソルを移動させる。同様に
?foo?-
?foo?-1
はカーソル行より前の foo を検索し、その前の行にカーソルを移動させる。

オフセットを付加したとき、モーションは行志向であるとみなされる。ところでこのオフセット機能は POSIX で定義されているものなのだが、オフセットを付加した時の桁位置はどうなるのかというとなぜか記述されていない。大抵の場合、行志向のモーションはカーソルをその行の最初の非空白文字に置くので、そうした。vim もそうなっている。

ちなみに POSIX ではデリミタ以降にオフセットではない余計なものがついてたらエラーにしなさいとか、オフセットを計算した後の行位置がバッファの先頭行や最終行を超えていたらエラーにしなさいとか、オフセットの他に z コマンドも有効としなさいとか言っているのだが、その辺は実装していない。vim も実装していない（たぶん）。

ノーマルモードでの [cci]^A[/cci]、[cci]^X[/cci] を作った。このコマンドは [cci].[/cci] の対象にもなる。

次に、bound モードでの動作を考える。vim では visual/visual line/visual block モードでも増減ができる。ノーマルモードではカーソルが位置する数値文字列が対象になるが、visual 系（謎）モードでは、選択された領域の各行の、最も左端にある数値文字列が対象になる。これは若干違和感がなくもない。選択された領域内のすべての数値文字列が対象になってもおかしくないのではないのか？　後で考える。

ちなみに、それを作るときにも書いたが、vim における visual 系モードは wasavi では bound/bound_line モードになっている。なぜモード名を変えたのかといえば、そもそも vi というものが ex の visual モードにほかならないからだ。命名がダブっている。

　＊　＊　＊

bound モードでも動作するようにした。vim と違い、領域内の全ての数値文字列が増減の対象となるようにした。

それから、vim のように [cci]set nrformat+=octal[/cci] などという特殊な代入をできるようにするかどうかだが、とりあえず、保留。

最近日本語の文章をちょっと多めに書く機会がある。そのために端末上の vim を使っているわけなのだが。

いまさら書くまでもないのだが、vi と IME を経由した入力の相性はとっても悪い。特に、ノーマルモードにいる状態で IME がオンになっている場合にぐぬぬとなる。せめてこれだけでもなんとかならないのだろうか。

IME が fcitx 上で動いている場合、[cci]/usr/bin/fcitx-remote[/cci] コマンドによって IME の状態を操作することができる。なので、vim のそれっぽいイベントに自動コマンドを引っ掛けて fcitx-remote を適当に呼んでやる。

autocmd InsertLeave * silent! !fcitx-remote -c

こうすると insert モードを抜けた時、必ず IME がオフになる。これでいくらかましになるかなー。

ちなみに wasavi の場合、ノーマルモードに戻るとやはり自動的に IME が無効になるようにしてある。実はノーマルモードでキーボード入力を受けるのは、隠された input[type=”password”] 要素なのだ。大抵のブラウザが、この要素がアクティブなときは IME を無効にすることを利用している。

残念ながら、IME の状態を直接的に制御するような API は javascript にはまだない。

issue #145。

これは、vimの [cci]^A[/cci] および [cci]^X[/cci] が欲しいよという要望だ。これらは、カーソルの下にある数値らしきものを指定したカウンタの分だけ増減させる。[cci]^A[/cci] は増加させ、[cci]^X[/cci] は減少させる。

オプション [cci]nrformats[/cci] の値によって動作をカスタマイズできる。これはカンマ区切りで文字列を格納する前提になっていて、以下のコンポーネントが意味を持つ:

• alpha – \b[a-zA-Z]\b をアルファベットのリストアイテムと認識する。大文字か小文字かで分類し、それぞれ [a-z] と [A-Z] をローテーションする
• bin – 0b[01]+ を2進数表記と認識する
• hex – 0[xX][0-9a-fA-F]+ を16進数表記と認識する。大文字か小文字かどちらかを取るかは、マッチした文字列の最も右端に位置するアルファベットに依存する。アルファベットがない場合は、2文字目が x か X かに依存する。
• octal – 0[0-9]* にマッチし、かつ、0[0-7]* にもマッチする部分を8進数表記と認識する。なぜこれだけ判定がややこしいのかというと、00018 のような文字列を 0001 と 8 に分割されてしまうのを避けるため。またこのコンポーネントを有効にすると、どうでもいいことだが C 言語と同様 0 は8進数の0と認識される

これらのコンポーネントに対するマッチの最後に、必ず -?[0-9]+ を10進数表記と認識する処理が入る。で、カーソル行に対してマッチした文字列群のうち、カーソルの桁位置を内包するものが処理対象になり、指定したカウンタの分だけ値を増減する。基本的には以上だ。

いくつか気を付けるべきポイントがある。

• 0 で始まる、10進数以外の数値文字列の場合、値を増減してもできるだけ元の桁数を維持するよう適宜左に 0 をパディングする
• 10進数と認識される数値文字列（これには、0で始まるが [89] を含む数値文字列も含む）の場合は、逆にいかなる場合も先行する 0 をすべて削除する
• vim の仕様だと、-0001 みたいなのは octal を含んだ nrformats の場合に若干不自然な動作になる。つまり負の符号が先行しているが、正の8進数文字列と認識される。これはいいのか？
• Selenium のテストで、あるテスト中に複数のアサーションを行う時、”#1-1″ とか “#1-2” とかラベルをつけている（そもそも複数のアサーションを詰め込むべきでないとか、もっと自己記述的なラベルにすべきとかはこの際置いといて）このラベルの右端の数値を増減させたい場合、ハイフンが邪魔になり動作が反転してしまう。これはなんとかならないのか。つまり負の符号ではなくハイフン、あるいは減算の演算子であるかを判別できるといいんだけど
• vim では、nrformats の型は文字列だが、実質的にはカンマ区切りの配列構造として扱うことになる。これは身近な例で言えば DOM における className と classList の関係に似ている。全体をまるごと書き換えるのでなければ、classList を通して操作するほうが圧倒的に便利だ。同じことが vim にも言えて、[cci]set nrformats+=foo[/cci] とか、[cci]set nrformats-=bar[/cci] のような演算子が用意されている（vim の、というか vi の set 構文はいわゆる普通のプログラミング言語とは若干趣が異なるので演算子と言っていいのかはわからないが）。これを wasavi でもサポートすべきか？