関数の頭で [cci]Array.prototype.slice.call(arguments)[/cci] としているしている箇所がけっこうある。Arguments を配列に変換する関数を書き、それを使用するように修正。

変数 runLevel を削除。これは何かと言うと、vi コマンド（含 ex コマンド）の実行のネストレベルを表していた。例えば、ユーザーが直接入力したキーストロークから実行される vi コマンドがレベル 0 として、そこからさらに実行されるキーボードマクロとしての vi コマンド群はレベル 1 である。

レベルを区別する理由は、レベル 0 の場合は適宜ビジュアルな要素（つまりステータスラインの状態とか、カーソルの形状とか、カーソル近辺までスクロールさせる必要があるとか）を更新しなければならないのに対し、まとめて実行されるレベル 1 では本質的にはそれを考慮する必要はないということである。レベル 0 に戻った時点でつじつま合わせをすればいいのである。それにより処理の高速化が図れるはずであるのだけど、とりあえず削除した。ただレベルの概念自体が不要というわけではない。将来的には何らかの形で再実装するかもしれない。

wasavi の iframe の最小幅については従来 320px と定義していたが、最小高についても 240px を下限とした。

DOM Range オブジェクトを使用した際、使い終わったあと detach() していたのだけど、これをやめた。そもそも存在理由が微妙なメソッドではあったが、DOM4 で公式に何もしないものと定義された。もしかしたら Presto Opera では超重要な意味を持っているのかもしれないが、まあいいよね。

キー入力周りをいじる。これは https://github.com/akahuku/wasavi/issues/35 への対応である。

wasavi のキーボード周りはちょっと…いやかなり複雑で、keydown や keypress イベントに引っ掛けたリスナで即 vi 的な処理を行っているわけではない。

まずキーボードマネージャというものがあり、この中で keydown と keypress、および composition events をまとめて扱っている。特に Opera 用の composition events エミュレータ層はかなりうんざりさせられる複雑さである。キーボードマネージャ内でいろいろなつじつま合わせを行った後、改めてキー入力イベントを発生させる。

次にマップマネージャがあり、これがキーボードマネージャからのイベントをリスンしている。これの仕事はもちろんマップの展開である。適宜マップの展開を行った後、改めてキー入力を発生させる。

最後に wasavi の process() がそれを受け取り、モードに応じた処理、abbreviation の処理、対応するカッコの点滅処理、および自動的なフォーマットの処理などなどを行う。などなどである。この他にもいろいろな処理がある。

複雑なのは、あいまいなマップの展開で次の入力に応じて展開を決定する場合や、クリップボードの読み書きを行う場合や、ex コマンドの実行完了を待つ場合や、スクロールコマンドの処理完了を待つ場合など、動作が非同期に行われる箇所があるのだ。これら全てに正しく応答しないといけない。

一方、dot コマンドやキーボードマクロを任意のタイミングで実行するためにキー入力をエミュレートしなければならない部分もある。実はこちらで非同期処理への対応が不完全だったり同じような処理が分散しているのである。このへんを直したい。

まずキーボードマネージャ内にデキュー、つまり double ended queue を設けて、発生したキー入力イベントをこれに押し込んだ後、FIFO 的にイベントを発生させるようにした。キューではなくデキューなのは、マップの展開が行われた場合、展開されたシーケンスはキューの最後ではなく先頭に押し込めなければならないからだ。

それからデキューのロック機構を設けて、非同期処理が間に入った場合は適宜ロックを行うようにした。

ただ、ファイル I/O 系の ex コマンドの実行を途中で中断する場合などに [cci]^C[/cci] を押した場合は、まさに SIGINT 的な特別扱いをしないといけない。

キーボード周りとは関係ないけれど、先に挙げた issue では map コマンドの右辺でダブルクオートを書けないよ、というバグが指摘されている。実はこれはバグではなく、POSIX では map コマンドの引数中のダブルクオートは [cci]^V[/cci] でエスケープしなければならないのである。vim はダブルクオートをそのまま map の引数として扱う（vi compatible にすればたぶん vi 通りの動作をするのだろう。未確認）。そんなわけで同時にそのへんも直した。

というわけで、wasavi に組み込んだ。

設定ページに javascript を書く。関数の名前に意味があり、編集可能な要素上では [cci]edit_[/cci]、そうでない場合は [cci]view_[/cci] から始める。次に、修飾キーがある場合は [cci]s_[/cci]、[cci]c_[/cci]、または [cci]sc_[/cci] を続ける。最後にキー名を付ける。ここまで指定した情報がそのままその関数が実行されるコンテキストを示している。

ここで指定した関数が実行された場合、それはページ上のスクリプトによるキーハンドリングより排他的に優先される。たとえば Twitter や slashdot など、[cci]j[/cci]、[cci]k[/cci] キーに特別な機能をもたせているサイトは少なからずあるが、[cci]function view_j[/cci] などを定義した場合はページ側の対応するキーバインドは無視される。

Linux にも Blink Opera がリリースされて以来、結構使っている。Presto Opera と同時に立ち上げて、気分によってどちらかを使っている的な状態だ。あるいは、ナウそうなサイトは積極的に Blink Opera を選択しているかもしれない。Presto Opera では操作不能に陥るくらい重いサイトが Blink Opera ではまあまあサクサクだったりするからだ。

とはいうものの、もちろん Blink Opera より Presto Opera のほうが優れている点も少なくない。例えばキーボードまわりのカスタマイズ性だ。Presto Opera はブラウザ上だろうがアドレスバー上だろうがあらゆるキーボード入力をカスタマイズできるが、Blink Opera にそういう機能はない。

ちなみにそれほどキーバインドを変えまくっているわけではなくて、

• [cci]c-h[/cci] でページを戻るか、戻れなければページを閉じる
• [cci]space[/cci] でビューポートの高さの半分 だけスクロールする
• [cci]j[/cci]、[cci]k[/cci] で 1 行ずつスクロール
• [cci]h[/cci]、[cci]l[/cci] でタブを切り替え
• [cci]c-b[/cci]、[cci]c-f[/cci]、[cci]c-n[/cci]、[cci]c-p[/cci] あたりを textarea に対して定義
• [cci]c-b[/cci]、[cci]c-f[/cci]、[cci]c-n[/cci]、[cci]c-p[/cci] あたりをアドレスバーに対して定義
• textarea 上での [cci]c-h[/cci] をカーソル前の1文字削除にする

この程度である。かわいいものである。これをなんとかして Blink Opera に持ってきたいのだけど、どうすればいいだろうか。

まず考えられるのは、そういうキーボードコンフィグ系のエクステンションがすでにあるよね、なくても Chrome 版をむりやり動かせばいいよね、ということだ。しかし、問題は、[cci]c-h[/cci] なのである。これの場合、単にキーに機能を割り当てるのではなく、条件判断が必要になる。そういうことを許してくれるエクステンションはあるだろうか？　たとえば Keyconfig は許可してくれるだろうか？

しかしどうやら Keyconfig はそういうことはできないようだ（できるのならごめんなさい）。YakShave ならできるかもしれないが、何やらローカルに web サーバを立てる必要があったりとなんだかめんどうそう（ごめんなさい）。

というわけで、もしかして、wasavi に組み込んだほうが早いんじゃねーの！？　という気分になりつつある。

wasavi の起動時に効果音を出すようにしてみた。

そうすると、当然「そんなのいらねーです！」というリクエストが来ることが考えられる。したがって音を出すかどうかを設定できるとうれしい。

ところで起動時の効果音というのは、wasavi が起動する前に鳴らすわけなので、つまり wasavi 本体が管理する設定（[cci]:set[/cci] で制御できるもの）とは別になる。そこで、オプションページで設定することになる。オプションページに効果音のリストとそれを鳴らすかどうかのチェックボックス、そしてボリュームの設定を置いた。

ところで従来は、wasavi が出す音といえばエラー時のビープ音であった。それは [cci]bellvolume[/cci] で設定できたのだけど、ビープ音も前述の仕組みで鳴らすようにしたので bellvolume は obsoleted になった。

wasavi を構成するコンポーネントとして

• バックエンド
• フロントエンド: エージェント
• フロントエンド: wasavi 本体

の 3 種がある。バックエンドはいわゆるエクステンションのバックグラウンドスクリプト、フロントエンドはコンテントスクリプトなどと言われるものである。エージェントは textarea 要素を持つページにアタッチされて、wasavi を起動させるかどうかの監視などを行う。

これら 3 つが協調することで wasavi が動作する。協調するためにはメッセージングを行う必要がある。

フロントエンドとバックエンド同士のメッセージングは、各ブラウザのエクステンションがその仕組みを提供しているので問題はない。一方で不思議なことに、どのエクステンションも、ドキュメント同士のメッセージング機構はない。

おそらく、ドキュメント同士なら html の規格通りにクロスサイトメッセージングを使ってね！　ということなのだろう。でも、[cci]window.postMessage()[/cci] によるやりとりというのは非常に汎用的なものなので、つまりだれでもリスンし放題なのである。怪しげなサイト上で wasavi を起動したりした場合、エージェントに対してクリティカルな情報（たとえば、wasavi のレジスタの内容は更新されるたび同期のためエージェントに内容が通知される）を直接投げるのはちょっとこわい。

ということで、ドキュメント同士のメッセージングとしてはバックエンドを経由してエクステンションのシステムの中で完結するようにした。正確には、もともとそうなっていたのだけど、ここ数ヶ月のソースは [cci]window.postMessage()[/cci] を使うようになっていた。それを元に戻した。

そして、そろそろ各ブラウザのエクステンションストアに置いてある版もここのところのテストが終わったら更新する頃合いだと思う。

wasavi のフロントエンドとバックエンドとの通信の方式について若干の変更を行いたい。

そのあたりはもちろん kosian 側で抽象化してあるのだが、wasavi はまず Chrome 上で作り始めたので、Chrome のエクステンションにおけるバックグラウンドとコンテントスクリプトの通信の作法をだいたいそのまま持ってきている。

つまり
extension.postMessage(message [, callback])
というメソッドを用いる。この callback がこの記事の主役である。

この callback を指定することにより、投げたメッセージに対する直接の応答を得ることができる。つまり非常に限定されたメッセージリスナとみなすことができる。一方、フロントエンドはコンテントスクリプト毎の汎用メッセージもリスンしていて:
chrome.extension.onRequest.addListener(handleMessage);
こちらは例えば他のタブで動作中の wasavi で設定が変更されたという同期通知や、dropbox（など）からのファイル読み込みの進捗通知などを扱う。

要するに、2 種類のメッセージリスナを扱っている。この状況で、それぞれが扱うメッセージの性格が完全に分離されているのならば、別に 2 種類あることは悪いことではないのだけど。がしかし上記のファイル読み込みの進捗通知というものが、微妙にどっちつかずな存在なのである。

ファイル読み込みは、フロントエンドからバックエンドへパスなどを渡し、バックエンドで認証などを済まし、読み込むためのリクエストを発行し、その結果をフロントエンドへ返す。フロントエンド側で見るとこの処理は ex コマンド [cci]read[/cci] の処理ということになり、そのハンドラの中で完結するはずのものである。が、実際は [cci]read[/cci] コマンド実行中のバックエンドからのメッセージは、汎用メッセージ側で処理している。これはやや不格好だ。

なぜ postMessage() の callback を使わないのかといえば、つまり [cci]read[/cci] 実行中、バックエンドからのメッセージは複数回送信されるからである。callback は 1 度呼び出されて終わりなのだ。これを拡張し、複数回 callback が呼び出される構造にすれば、必要な処理はすべて [cci]read[/cci] ハンドラの中に掛けば済むようになって、収まりがよいはずだ。

というわけでそうした。ここで、ソースの修正は割とすぐに終わったのだけど、実際に Opera 12 で動かしてみるとさっぱり狙った動作をせず、あーでもないこーでもないとした挙句、単に Opera を再起動させたらちゃんと動くようになったというなんとも言えない事件があったのだが、まあ Opera においては特に珍しいことではないので、いいのだ。