AMO へ wasavi 0.5.329 をレビューに出してかれこれ 2 ヶ月くらい経っているのだが、音沙汰がない。レビューに出している間に何度かメールでのやり取りをしているのだが、dropbox に対しての読み書きについてテストの手順を教えてくれとのリクエストに 7 月 30 日に返事して以来音沙汰がない。キューの位置は 10 of 145 である。よほど巨大なアドオンが前に詰まっているのか？
あまりに時間がかかるので、AMO へ提出する Firefox 版は当分ベータバージョンにするかもしれない。つまり 0.5.351beta のようになる。
vim から拝借してきた機能の一つにプリフィクス付きの文字入力というものがある。
insert/overwrite モード、あるいは ex コマンド入力中に ^V を押すと、次に入力する文字がその文字そのものとして入力される（ただし insert/overwrite モードで ^M、^J を入力した場合のみは enter を入力した場合と同様に改行が行われる）。これはおもにコントロールコードの入力に使用されるのだが、wasavi では ^V に続けて数字、または o/O/x/X/u/U を押した場合はさらに特殊な状態に遷移する。
^VU でのコードポイント入力は Unicode の BMP を超えた先も対応していて、その場合はサロゲートペアが生成される。
昨日の記事を書く過程で wasavi に言及しているブログなんかをぐぐってみた。で、何件かあった。それ自体は、非常にありがたいことである。あるのだけど、その中にちょっと気になるものがあった:
これは、テキストエリアを編集中に規定のキー(例:Ctrl+Enter)を押すと、Vimモードになり、:q を入力するまで、Vimのキーバインドを提供してくれるもの。
vimscriptによるプラグインは使えませんが、Vimとしての再現度はなかなかよいと思います。
何が気になるといえば、つまり「Vim」の一語だ。
wasavi は vi のクローンであって、vim の何かではない。vim からいくつかの機能を拝借してはいるが、wasavi は vi のクローンであって、vim の何かではない。
したがって、vimscript が動かないんですけお！ と言われても困るし、「vim の再現度」について評価されても「えっなんのこと？」としか答えることができない。なにより説明で “vi editor for any web page” と言っているのだ。なぜ vi ≒ vim という取り違えが起きるのだろうか？
これはつまり、現役の vi 系エディタのデファクトスタンダードが決定的に vim であるという現実がやはり根底にあるのだと思う。古い人間なら、vim なんて遅れてきた vi クローンの上にやたらめったら魔改造を施された、ある意味での異端児だ、などと思うだろう。つまり彼らにとっては、vi と vim は明らかに別のものである。しかし新しい人間にとっては、vi といえばつまり vim であり、vim のオリジンは vim 自身であり、historical vi はそのタイニー版でしかないということなのではないか。
将来 wasavi にスクリプティングやシンタックスハイライトの機能を実装するとして、その仕様はおそらく vim のそれとはかなり違うものになると思う。つまり今以上に「vim となんかちがうんですけど」的な扱い難いクレームが増えるかもしれない。これはなかなかに由々しき問題だ。
wasavi は Chrome、Opera、Firefox にそれぞれリリースしている。その中で、Chrome と Firefox はアクティブユーザー数を知ることができるのだけど、それぞれ 300 人台とか、100 人台とかである。これは、他のエクステンションを適当に眺めてみる分には、かなりつつましい数字だ。
これをたとえば万のオーダーにするには、やはりどこかのサイトで紹介されて爆発的に知れ渡る的なイベントが必要なんだろう。そして、それが起こるのを待つと言うよりはむしろ、こちらからいろいろな IT 系ニュースサイトに「wasavi を紹介してくださいお願いします」といった営業活動をしなくてはならないんだろうと思う。
しかしめんどくさそーなので別にやらないのであった。そもそもよく考えたら、ユーザー数が増えても別にメリットないじゃん。
Selenium に実行させるテストの総数が 666 になった（アサーションの総数は 2700 くらい）。
全コードの 66% が wasavi、33% がテストコードである。うーん半々くらいに持ってきたいところだが……。
クリップボードを介した貼り付けについて、Clipboard API をちょっと使用してみた。
貼り付けなので、ctrl+v か、shift+insert を押した場合に document に対して paste イベントが発生する。イベントハンドラの中で e.clipboardData.getData(‘text/plain’) とかすると貼り付けようとする文字列が得られる。その文字列を vi のコンテキストに従って適切に貼り付ける。また、e.preventDefault() してデフォルトのアクションは取り消しておく。
ただし、ctrl+v は挿入モードや行入力モードでのエスケープシーケンスの入力開始文字とかぶっている。そこで、貼り付けイベントを認識するのは shift+insert だけにした。この特別扱いを行うと、そのキーを再マップできなくなってしまうので、なおのこと ctrl+v は明け渡すことはできないのだ。
これにより、Presto Opera で wasavi を動かしている場合でも、限定的にクリップボードを使用することができるようになった。限定的というのはまず、書き込みはやはりできないということだ。また、コマンドモードで shift+insert した場合でもとりあえずクリップボードからの貼り付けを行うようにしたのだが、内部的には [cci]”*p[/cci] を実行するだけであり、エクステンション側でクリップボードの読み書きが自由にできない Presto Opera では動かない。
ついでと言ってはなんだけど、キーボード入力のハンドラで入れ子になっているコールバック関数を外に出した。つまりキー入力ごとに関数の評価を行なっていただろう箇所を取り除いたのだけど、なんか目に見えて入力のスピードが速くなった？ えっそんなに差があるの。
javascript 製の vi というものをググってみると、以前から JS Vim なるものがひっかかるのだが、概要に述べられているリンクが 404 だったり、ドキュメントの類が一切なかったりで、何者がどういう意図で作ったものなのかよくわからず、気になっていた。
どうも ここ が現時点で有効なサイトのようだ。ページ上に実装済みの機能が示されているが、それほど多くはない。また、ex コマンドのたぐいはまだ実装されていない。
作った人の位置づけとしては vi clone ということらしいのだが、個人的な感覚で言えば、ex コマンド群を実装せずに vi clone と名乗るのは良くない。それはせいぜい「なんちゃって vi clone 見習い心得」くらいのものだ。
それはそれとして、sourceforge 上のソースは 2.0 だが、件のページでは 3.0 と地道に更新されているようなので、頑張ってほしいと思った。
Opera Next 16.0 が公開されていた。それほど目新しい新機能が追加されているわけではない（開発中のものは opera://flags から幾つか試すことができる）。
Presto Opera ユーザーが納得する出来に到達するには、Opera 18、いや 20 くらいまでは待つ必要があるだろう。
15、16、17 と…… Opera の人生暗かった。
リリースした。Google Drive への対応と ex コマンド入力時の各種補完がメインになっている。
ファイルをアップロードするために Google Drive が提供する API を呼び出す際、Exponential Backoff なる方式にするといいよ、と google 先生は言う。
なにやら難しい専門用語である。exponential とは指数のことだ。しかし内容はわりと明快で、ファイルをアップロードした際に何らかのエラーが発生した場合のリトライの待機時間をべき乗則にするといいんじゃね？ ということである。
wasavi ではこれは実装していない。書き込みが失敗したらエラーだよ♪ と表示されてそれだけだ。ファイルへの書き込みはユーザーが明示的に指定するので、エラーが発生したらユーザーが再度指定すればいいのである（このインターフェースには異論はあるかもしれない）。
Windows Vista から導入された UAC というものがある。それにともない、Administrator 権限を持っているユーザーであっても通常は制限された権限、必要なときは権限のエスカレーションを行う、といった *nix 的な作法に慣れていると無駄に複雑だなーと思える機構が導入された。同じユーザでもコンテキストによって権限が行ったり来たりするのである。
一方で Administrator 権限を持つアカウント、一般ユーザー権限のアカウントをそれぞれ作り、通常は一般ユーザーでログオン・作業し、必要なときは Administrator 権限を持つアカウントのユーザーのパスワードを入力する、という運用もできる。コマンドプロンプト上でのシンボリックリンクの作成が、こちらの運用方法じゃないと機能しないので、うちではそうしている。
さて数日前 VirtualBox の新しいバージョンが公開されたというので、一般ユーザーでログオンしている状態でダウンロードし、インストーラを実行させた。すると、インストール自体には成功して GUI のフロントエンドは起動するのだが、VM を立ち上げようとすると Kernel Driver が云々といったエラーで実行されなくなってしまった。また、extension pack を更新しようとしても、何やら権限が足りません的なエラーが出る。
これはおそらく前述の、一般ユーザーでログオン + インストーラ実行時に Administrator 権限のユーザーに仮想的にスイッチ、という環境特有のものなのだと思う。おそらくインストーラが複数のプロセスで構成されていて、子プロセスに正しく権限が継承されないまま実行されてしまっているのではないか？ と考えて、Administrator 権限を持つユーザーでログオンしなおし、VirtualBox のインストーラを再度立ち上げ、修復インストールした。すると、一般ユーザーでログオンした状態でも正しく起動するようになった。