AMO の中の人の手元でもサーバーエラーになるそうなので、bugzilla に登録してもらった。
うーんこちらで直接登録してもよかった気がするが。まあでも中の人……というか「the Add-ons Developer Relations Lead for Mozilla」という肩書きのおかげか、あるいはアサインとかも最初から割り当てられてたせいか、すぐに修正されたようだ。あとは、そのパッチがレビューされて実際に適用されるのを待つだけということかな。
長かったなあ。
関係ないけど、wasavi の preliminary / full review をしてくれた方は Pentadactyl の開発者の一人ということで、vi 繋がりなのかと思ってたら、単にものすごく多くのアドオンをレビューしているだけだった。なーんだ。
relativenumber を実装してみたが、カーソルから上の領域の行番号が負の符号付きになる件。これはこれでしかたないかなーと思っていたところ、コメント欄で間接セレクタを使えばいいと教えていただいた。
あー、間接セレクタね！ うんうん間接！ 間接……間接セレクタってなんだっけ？
バカにしないでくれる！？ 知ってるわよそれくらい！！（ググりながら）
というわけで無事 vim の relativenumber と同様の見た目になった。ありがとうありがとう。
そういえばすっかり忘れていたが、AMO に新しい xpi をアップロードできない件。
（先週の）金曜になったら試してみてね！ などと言うから期待していたのだが案の定同じサーバーエラーが帰ってくるだけだった。枕を涙で濡らしつつ、再び AMO の中の人にメールしたら、xpi を送ってみろというので送った。
個別に対応してくれるのはありがたいけど、サーバーエラー時のメッセージをもうちょっと詳しく出すように改修してくれないかなあ。次またエラー出たらまたこのやりとりしろというのだろうか。
お願いしますよ Jorge さん。
「relativenumber、いいよね」「いい……」
vim の機能を全て知っているわけもないが、知ってる機能の中で、初めて知ったとき最も衝撃的だったのは relativenumber かもしれない。relativenumber 好きだ、大好きだ。お前が好きだ、お前が欲しい！
というわけでこっそりと wasavi へ移植する。
内部的には、wasavi の行番号は css のカウンタだ。したがって、操作できるのは counter-reset、counter-increment くらいで、それほど自由度があるわけではない。そういう環境下でカーソル行を 0 とした相対的な行番号ぽくするには、バッファの counter-reset を -(カーソル行位置+1) で初期化する。カーソルの上方向は負の符号付きになってはしまうが、これでだいたい目的は達せられる。
しかし実際に作ってみるとやっぱり負符号が気になる……。
ということで、表示行単位でカーソルを上下に移動させるコマンド gj、gk を実装した。また、オプション jkdenotative を追加した。これがオンの状態では、単なる j、k が表示行単位で移動し、gj、gk は物理行単位で移動することになる。そして重要なことに、jkdenotative の初期値はオン、にしようと思う。
それにしても jkdenotative ってものすごく覚えにくいな。なんかいいのないかな。
さて vim では gj、gk のほかに g0、g^、g$ なんかもある。というかもっと他にやたらある。全部はいらないので、g^ と g$ くらいは作るかな。これらも jkdenotative の影響を受けることになる。とても重要。
バッファ内において「物理行」を改行で区切られたそれぞれの領域とする。1 つの物理行を表示した際、ビューより長いものは折り返される。このとき折り返された、折り返しポイントで区切られたそれぞれの領域を「表示行」とする。
j コマンドや k コマンドは、物理行単位で移動する。ものすごく 1 行が長い物理行のうえでこれらのコマンドを実行すると一気にスクロールが行われて面食らう。
vim では、gj とか gk コマンドが用意されていて、これらは表示行単位でカーソルを上下に移動させる。vi にはない。
次はこれを持って来たいという話。
この機能を作る準備として、1 行内のその折り返しポイントを得ることを考えなければならない。できれば一発で取れる夢のような API があればうれしいのだが、ない。getClientRects() あたりが惜しいのだけど（これは各表示行についての座標情報を返す）、折り返しポイントは返してくれない。
うーん地道にループ回すしかないかな。
ところで vim で表示行を使う際、[cci]noremap j gj / noremap k gk[/cci] すると便利ですよ奥さん！ 的な話題になりがちだと思う。でもこれは割とバッドノウハウなんじゃないのかなー。ぶっちゃけていうと j/k は常に表示行単位で動かすようにしても別に困らないと思うんだけど。移動単位を切り替えるオプションくらいは新設する必要があるかもしないが。
LocationChange イベントのハンドラで、document に対して wasavi の起動と終了イベントをリスンさせているのだが、これはなかなかに乱暴だ。つまり、リスンさせっぱなしなのだ。
本来なら、タブが切り替わる直前に document からハンドラを取り除きたい。しかしそういうイベント（BeforeLocationChange みたいなの）はないようだ。LocationChange イベントは実質的に AfterLocationChanged だ。
したがってその結果、タブが切り替わるごとに同じイベントハンドラを何度も登録するというちょっと餡子の足りない動作になってしまっている。もちろん同一のイベントタイプ・ハンドラ・キャプチャフラグで何度 addEventListener を呼び出しても、登録は高々 1 度だけに収束するという DOM の仕様が前提なわけだけど。
Invoking addEventListener (or removeEventListener) repeatedly on the same EventTarget with the same values for the parameters type, listener, and useCapture has no effect. Doing so does not cause the event listener to be registered more than once and does not cause a change in the triggering order.
それと、現状では wasavi が終了すると共に [cci]passAllKeys = false;[/cci] しているのだけど、これだと wasavi に関係なく常にパススルーで動かしたいサイトで誤動作することになる。wasavi が起動する時点での passAllKeys の値を保存しておいて、wasavi 終了時はその値に復帰させるとかすればよいのだが、passAllKeys が実質グローバルなことを考えるとそれでつじつまが合うのか不安だ。いや合わないケースが確実にある。
この周辺をバグ報告されても、vimperator の仕様がそうなんだよーとおあしす運動（「おれじゃない」「あいつらじゃないの？」「しらない」「すんだこと」）を開始せざるを得ない。どうしよう。
対象ページの window は、content オブジェクトが持っているみたいだ。なので、content.document instanceof HTMLDocument のときにそれに対してごにょごにょすればいい。
なお前の記事では MutationObserver を使うつもりでいたのだが、なにか使い方を間違っているのか、要素を追加・削除しても一切ハンドラが呼ばれない。しかたがないので MutationObserver を使うことはあきらめ、wasavi 側で開始・終了時に CustomEvent を document に対して発行するようにした。このイベントを vimperator のプラグイン側でリスンし、適宜 passAllKeys を書き換える。
ところで気になるのは、wasavi を適当なタブで起動し、そのまま他のタブに切り替え、また戻ってきた場合。この場合、LocationChange イベントのハンドラで、wasavi が起動しているかを見て passAllKeys を制御することになる。しかしここで passAllKeys を直接触らざるを得ないのは vimperator の間違った設計だと思う。LocationChange 内で passAllKeys を触るプラグインが複数あったら破綻してしまう。ハンドラ側では passAllKeys = true としたい、というリクエストを出すだけにして、ハンドラの呼び出しが全て完了した後に呼び出し側でリクエストの有無によって passAllKeys を制御する構造にならないかな。
まあそれはさておき、とりあえず編集したいときに wasavi を起動して終わったら即抜けるっていう使い方をする限りは動くようになった。やったね。
AMO 中の人からお返事が来ていた。金曜に再度試してみてね！ とのことである。金曜になったら直ってるんですか！ もうエラー起こらないんですか！ やったー！！
※たぶん直ってない
そういうわけでいろいろ調べてみると:
ということでそんな感じでプラグインを書いてみたのだが、うまく行かない。document.body 直下に iframe が追加・削除されたかどうか監視するために、MutationObserver を生成し、observe() する。
ところがこれが失敗する。MutationObserver#observe() するには対象の要素への参照が必要だ。つまりまず対象のページの window への参照が必要だ。そんなわけでこんな関数を:
function getWindow () {
var wnd;
try {
wnd = liberator.modules.Buffer.focusedWindow;
if (!wnd) {
log('target window not found.');
}
}
catch (e) {
log('exception occured while retrieving focusedWindow: ' + e.message);
wnd = null;
}
return wnd;
}
LocationChange に引っ掛けたハンドラ内で動かすと focusedWindow を参照したところで例外が起こる。vimperator 3.5 のソースを見てみると
getFocusedWindow: function (win) {
win = win || config.browser.contentWindow;
let elem = win.document.activeElement;
let doc;
while (doc = elem.contentDocument) {
elem = doc.activeElement;
}
return elem.ownerDocument.defaultView;
},
で、つまり elem が null のとき while の条件節でエラーになる。そりゃそうですね。
うわーん
動かないよー
うーんどうやって window を得たらいいのかな……。