github で、vimperator や pentadactyl と共存させるとうまく行かないとの issue をもらった。そうなのか。
というわけでちょっと試してみることにしよう。しかし最初に告白をしておくと、これらのアドオンへの深い知識はまったく持ち合わせていない。というよりそもそも Firefox 自体のことをあんまりよく知らないんですけどね……。まあいろいろ調べながらやってみることにしよう。きっとどうにかなる。
タイトルには深い意味が込められているようであんまり込められてない。
例の AMO のご乱心だけど、特に直っている様子はない。
というか、ググってみたりツイって（謎）みたりしたり限りでは AMO にエクステンションをアップロードできないよー！ 的なそれが見つからない。きわめて局所的な問題なのか？
bugzilla に登録されているバグ票では多少進展があったようだがまだなんとも言えない。休み明けもこの調子だったら追記するか。
＊ ＊ ＊
amo のエディタ（つまり編集者）にメールした。
あと、件の repack & compatibility-validation のメールが来ていて、そちらも「おめーのアドオンがエラーになってるから直せよな！ 死ね！」という内容だったのだがエラーの内容はやはりサーバ側のタイムアウトなのである。どうしろというのか。
で、返信しようとしたらそのメールの reply-to: が nobody@mozilla.org だという。なんか……なんかなー！
% コマンドは、カーソル直下、あるいは前方方向に最も近い括弧（({[）に対応する括弧へジャンプする。
「言われてみれば確かにそうだなあ」なのだけど、” や ‘ では % コマンドは働かない。vim であっても同じ。vim では括弧のペアは matchpairs オプションで “(:),{:},[:]” のように指定できるが、括弧の両端は異なる文字であることが求められる。
しかし内部的には、テキストオブジェクトで用いる関数はクォート文字で囲まれる領域の左右の各境界を認識できるのである。にもかかわらず % コマンドではそれを利用していない。
ということで、もったいないので wasavi では ” や ‘ や ` でも対応する境界へジャンプするようにした。あー、これはまあまあ便利かも。
AMO に行って wasavi の最新の xpi をアップロードしようとしたら、自動 validation に弾かれる。90 秒のタイムアウトで強制中断されるか、サーバの内部エラーで強制中断。何度やっても同じだ。なんだこれ。
今なにやら AMO では、AMO にアップロード済みの SDK ベースのエクステンションを最新の SDK で repack & compatibility-validation している/しようとしている状態らしいので（参考）、それが関係して一時的にアップロードできないのかもしれない。全然関係ないかもしれない。
Firefox(10日)、Opera(2日)、Chrome(即日) の順で更新版が公開されるのに手間と時間がかかるので、Firefox 版から先に片付けようとした先からこんな調子でずっこけた。
作った xpi の出来が悪いんじゃないのか？ という可能性はなくはないのだが、AMO へログインした後、すでにレビュー・公開済みの 0.4.175 を再度 validate してもやはりサーバの内部エラーになるので、やはり向こう側の問題のようだ。
もう、駄目な AMO ぞうさんですね。
＊ ＊ ＊
bugzilla に登録されていた。現象は 10 月 1 日からだそうです。でも中の人からの何の反応もなく誰にもアサインされてもいなくすでに 3 日が経過している。
うー。まさにこの気持ちだ:
くるぞう: できるだけ急いでくれよな
くるぞう: 3日経ってますけど・・・
コマンドモードのとき表示されるカーソルは、position:absolute な div であり、カーソル位置の 1 文字の座標、文字を得て適切な場所に表示している。
が、なんだか微妙にずれる。しかも、wasavi 起動するページによってずれ方が違うのである。wasavi は iframe 内のコンテンツなので影響は受けないはずなんだけど、謎だ。
そういうわけでカーソルの実体を変更してずれないようにした。けっこうな修正。
＊ ＊ ＊
バッファの有効な行以降には、vi 同様 ~ を表示している。この tilde、実は canvas に描画した画像であり、縦方向に連続しているのはつまり css の background-repeat の機能だ。
これ、Opera においては canvas に対する文字の描画がいろいろバグっているのか、やたら小さく表示されるのが気になる。これはまあ、そのうち直るだろうと踏んで手をつけないが、行番号を表示させた場合に折り返される行の左端に tilde が残るのが目障りなので、出ないようにした。これもけっこうな修正。
＊ ＊ ＊
編集モードに入った最初の段階でキャレットが表示されていなかったのを修正。これは軽い修正。
＊ ＊ ＊
ステータスラインは、wasavi が寄生する textarea の外側に位置するようにしている。つまり、textarea のサイズ = wasavi のテキスト表示領域のサイズになるようにして、ステータスラインはそこからはみ出すようにしている。が、chrome ではその調節がうまく行ってなかったのを修正。
はみ出させるか否かは、wasavi が iframe 内にあるか、トップレベルのブラウジングコンテキストかどうかを判断する必要がある。そのために、window.frameElement を見ていたのだが、chrome の場合これを参照するだけで例外が発生するのだ。chrome の場合だけ window.parent == window かどうかで判断するようにした。
とりあえずこんなところでまた各ブラウザのエクステンションリポジトリに更新してもらおうというところ。
例えば wasavi の起動時、終了時、あるいは何かエラーが発生したときなど、コード中の何箇所かで console.(log|error|info) している。これはデバッグの際にちょっと役に立つ。
さて実は、Firefox 版 wasavi の full review をしてもらった際、「次に更新するときはログは取っといてね。製品バージョンでふつうこんなことしねーから」と申し渡されている。そうか？ と疑問に思わなくもないがちょっと考えてみることにしよう。
前述の通りログはデバッグに役立つ。自分でコードを書いて自分で動作を確認するときはもちろん、製品版であっても「～が動かない」「～のログは出てる？」というやり取りがよくあるのであって困るものではない。しかしまあこれは譲歩しよう。開発時はログを出し、公開版では出さないようにする。これで文句はあるまい。
これはまるでネイティブアプリの Debug ビルドと Release ビルドみたいな話だが、もちろんブラウザのエクステンションにはそういう区別は特にない。実行時に自分が開発バージョンか否かを判断できるような何か代替になるものを作らなければならない。
現在 wasavi のバージョンは 0.4 である。これが例えば 0.0 に戻ることはありえない。そこで、0.0 = 開発版ということにしよう。manifest.json、config.xml、package.json のそれぞれのバージョン情報を 0.0.1 にし、バックグラウンドの起動時に保持しておく。また wasavi が起動した際は開発版かどうかを通知し、開発版のときのみ console.なんちゃらを実行するようにする。
ということでそうした。
ところでエクステンションが自身のバージョン情報を得る方法として、Opera は widget.version、Firefox は require(‘self’).version を単に参照するだけでいいのに対して、Chrome の場合は manifest.json に management パーミッションを追加した上で chrome.management.version を参照しないといけない。
Chrome エクステンションでパーミッションの拡大は割と一大イベントである。エクステンションが更新されたとき、「なんかこのエクステンションがさらなるパーミッション要求してるけど、どうする？」とか聞かれたと思う。こんなダイアログ出たらだいたいの人は怖がって漏らしてしまう。もちろん本当に重要な機能追加のためにパーミッション拡大が必要になったら、そのときはせざるを得ないが、ドキュメントに大書するなり web サイトでアナウンスするなりといったフォローもあわせて行う必要があると思う。
翻ってバージョン情報の参照だが、これはぜんぜん重要な機能追加でもなんでもない。どうしたものか。
＊ ＊ ＊
management API を使わず、直接 manifest.json を xhr で読んで version を参照するようにした。
だいたい出来てきた。[{()}] の動きも vim と互換になっている。ただし、いくつかの相違がある。
vi には sentence、paragraph、section 単位でカーソルを移動させるコマンドがある。それぞれの定義は正確になされている。
wasavi では、それぞれのブロックの境界を見つけるのに定義に従った正規表現で楽しようとしていて、それはそれでそれなりに動いてはいるのだが、実は現状の実装だと vim や nvi と互換な動きをしていない。ちゃんと互換させようとすると正規表現だけで済ますのはちょっと難しいかもしれない。特に空行の扱いが難しい。vim や nvi ではそれぞれ謎のルールの仕込まれたループで境界を見つけている。
そういうわけでそのへん、つまり search.c 内のブロック系関数一式もごっそり移植せざるを得ない感。ちなみに sentence の検索関数だけ見ると nvi のほうがすっきりして分かりやすい気がする。
そしてこれは wasavi 側にしてもなかなかに大掛かりな書き換えになるのであった。
＊ ＊ ＊
javascript 製のコードエディタ Ace の 1.0 が公開された。これは 1.0 未満の状態でも割と前から公開されていて、オンラインデモも試すことができた。そのなかで、キーバインディングを vim 互換にすることもできたのだが、その再現具合は長らく「ううん……」というものだった。
で、今回 1.0 に達したということで久しぶりに試して見たらけっこうよくなってた。でも ex コマンドはない？ 世の中の javascript で再現した系の vi クローンはなんでことごとく ex コマンドを実装しないのかなあ。
word
クォートされた文字列については終わったので、次に word、つまり iskeyword オプションに格納されている正規表現にマッチする文字で選択する機能。vim では、これもやはり search.c で処理している。current_word() である。これは特に記すこともなく実装した。
ひとつだけ特記しておくとするならば、aw と iw の違いだろうか。単語に付随する空白の扱いと言い換えてもいい。
foobar
^
^ の場所にカーソルがある状態で yaw すると、ヤンクされるのは
これは、前者はともかくとして、後者はどうなんだ。空白は word なのか？ いやー空白は単語ではないだろう……ということで、wasavi では vim とは違い、この場合 “foobar” がヤンクされる。
また、
foobar foobaz
^
の場合は、aw は
block
( ～ ) とか { ～ }、あるいは [ ～ ] の中身を選択する。これはもしかしたらいちばん簡単かもしれない。これらの中身との境界を認識する処理は、% コマンドを呼び出すだけだ。つまり処理のほとんどはすでに出来てあるのだ。というわけで、特に問題なく実装。
ただ、vim では { ～ } の場合だけインデント周りで特別な処理をしているのだけど、それが必要な意味がいまいち読み取れなかったので、実装していない。
sentence、paragraph
とここまではそんなに難しくない。難しいのは残りのセンテンスとパラグラフ単位の選択なのである。
気力が続けば続く。