wasavi からクリップボードを操作する場合、vim と同様レジスタ “* を使って y/d/p する。Chrome と Firefox はエクステンションがクリップボードにアクセスする API を提供しているので、問題ない。

問題は Opera なのだ。例によって。

一方、Opera は 12.50 で Clipboard API をサポートするという。これは何かといえば、ユーザがブラウザの提供するカット、コピー、ペースト機能を呼び出した時に、その本来の働きが行われる前にイベントとして取れるようにする、またそのイベントハンドラの中でクリップボードにアクセスできるようにする、その辺の仕様を規定したものだ。

重要なことに、これはカット、コピー、ペースト機能自体をスクリプタブルにするものではない。そういうことはできないと仕様に明示してある。ユーザが ctrl-c を押した時にセレクションの内容にかかわらずクリップボードには “ほげほげ” とコピーする的ないたずらはできるが、ユーザの知らないところでクリップボードを読み書きすることはできない。そういうあくどいことはともかく、たとえばブログでよくあるコードサンプルでの「ボタンを押すとコードをコピー」的なものもできない。

というわけで、Composition Events 同様迂回策を考える必要があるのだが……。まずクリップボードへの書き込みに関しては、かつては Flash を経由してできたかもしれないが、今は無理。読み出しに関しては、input モードで ctrl+v が押されたことを前述の Clipboard API を通じてキャッチし、デフォルトの動作をキャンセルした上で wasavi の動作として貼り付けることはできると思う。使い勝手は端末から vim を使ってる時に input モードで端末の機能を使ってペーストする感じに似ている。

ctrl+v はもちろん wasavi では vim 同様の特殊な文字入力のプリフィクスなので、やはり vim 同様 ctrl+q もプリフィクスとして認めるようにして ctrl+v は開けておく必要がある。

しかしこうしてみるとととても中途半端なものにしかならないなあ。ダメだなこれは。はやく Opera もエクステンションでクリップボードの読み書きできるようにしてください。

wasavi を呼び出すのに、textarea 内で特定のショートカットを押す。このときの手法は、コンテントスクリプトで document に capture フェーズの keydown イベントハンドラを引っ掛けるという極々ふつーのものだ。ふつー過ぎて、ページによっては時々この keydown イベントの監視による wasavi の起動がなされないことがある。

コンテントスクリプトはページ自体が持つスクリプトよりも早い段階で実行され、keydown イベントハンドラの登録もページスクリプトより先だ。イベントハンドラの呼び出しは登録順なので、つまりキー入力に対して wasavi の起動監視が最も早く行われるはずなのだが、なんで起動がなされないのかちょっと不思議。いろいろ追いかけてみる必要がある。あるのだけど、とりあえずのワークアラウンドとして textarea 上のコンテキストメニューに「Run wasavi」的なものを追加して、そこからも起動できるようにした。Opera にも 12.10 からエクステンションによるコンテキストメニューのアクセスが可能なのだ。ってすごい最近ですね。

ちなみにエクステンションによっては、hotkey 的な API を提供しているものもある。たぶんそっちを使ったほうが強力なのだろう。でもざっと各エクステンションの仕様を見る限り Chrome の commands API では動的にキーバインドを定義できない？　manifest に記述してそれだけなんだよね。というわけでまだそういうものは使っていない。Opera にそういう API ないし。

Opera と言えば、こうやって wasavi で書いてる間もなんか起動したりしなかったりする。これはどうも wasavi の問題ではなくて Opera のキャッシュがぶっ壊れている（iframe に読み込んだ http://wasavi.appsweets.net/ に対して、その injected script である wasavi.js が実行されない、ときがある）っぽいのが困る。設定からキャッシュを全削除して Opera を再起動すると直る。直らなかったりする。やめてよねそういうの！

ぼちぼち Opera でも安定して input モードが動作する頃になってきたような気がする。そろそろ公開するかな。ただ *nix で Composition Events のエミュレーション自体が不可能なのは対処のしようがないのが残念。*nix と書いたのはたぶん BSD とかでも同じだろうということで（試してはいない）。

ただまだ undo ログが不正になる時があるんだよなー。それを直したら公開しよう。

undo はほんとうに難しい。もしかしたら根本的に書きなおさないとダメかもしれない。

ページのリロード後も設定を持ち越す、という動作を実装する。先に書いたとおり、難しいのはリロード前に wasavi を起動させ設定を追加した textarea が、リロード後に必ずしも同じノードパスとは限らない、という点だ。これは、ノードパスを文字列化したもののレーベンシュタイン距離をとり、適当な閾値以内かどうか、で判断すれば良いと思う。

一方、ページのリロードではなくフォームの送信のように URL が変化する場合もある。また、URL のパスは同一でも、クエリ文字列やフラグメントが微妙に変化する場合もある。つまり URL についても類似性を見る必要があるかもしれない。例えば example.com/?foo=bar 上の textarea に対する設定は、example.com/?foo=baz をブラウズしたときも同様に再現されてほしい。ただしこれは微妙かもしれない。クエリ文字列やフラグメントが 1 文字変化しただけでまったく異なる内容を提供される場合もないとは言えないからだ。しかし、類似性を見て得る情報はしょせんエディタの設定だ。間違えたところで、今のところはそんなに危険というわけでもないので、まあいいだろう。

URL については構成部品ごとに分けて考える必要があると思う。パス部分は曖昧な類似性は関係ない。同じか否かで見る。一方クエリ文字列は難しい。& で連結される key=value の部分は順不同だからだ。?foo=1&bar=2&baz=3 と ?baz=3&foo=1&bar=2 は実質同じクエリ文字列だが、レーベンシュタイン距離は結構な値になる。そうすると、クエリ文字列の類似性はレーベンシュタイン距離ではなく、trigram による similarity measure を見たほうがいいかもしれない。

　＊　＊　＊

そんな感じで組んでみた。覚えておく URL は直近の 30 件、類似性の閾値は 0.8 とした。