Chrome で Ctrl-[ntw] を使うことができない件。

その代わりに Alt-[ntw] でも同じ機能を呼び出すようにした。Selenium でのテストもそちらを使用する。

ついでと言っては何だが、[cci]map[/cci] の左辺に指定するキーストロークで Alt を併用したものを受け付けるようにした。ただし完全ではなく、保証できるのは Alt-[a-z] だけ。この辺は DOM3 KeyboardEvent がフルに実装されればもうちょっとましになると思う（つまり、キーボードレイアウトに依らずにすべてのキーについて何が押されたかを正確に判断できる）のだけど、それはまあ 1 年後くらいかな…。このへんは何故か Chrome のほうが W3C の規格からずれている。

中長期的な目標のうち大きめのものを一応メモしておこう。

まずはモデルとビューを分離したい。現状では wasavi が保持しているテキストの実体は iframe に表示されている html 文書そのものなのだ。それにより再表示の部分は完全にブラウザ任せにできるメリットはあるのだけど。しかしせいぜい 100 行程度の小さな文書であればいいのかもしれないが、それ以上になるとメモリ消費量や再表示の速度などなかなかきつくなってくると思う。

なので、テキスト自体は単なる String の配列か、あるいは XMLDocument にしておいて、表示の部分はまさにビューに表示すべき領域だけを描画するようにしたい。スクロール処理も含めてそのためのプロトコル的なものを考える必要がある。

それからモデルとビューの分離は、もうひとつ重要な変化をもたらす。現状 wasavi のエディタ部分のコードはすべて iframe 側にある。つまり wasavi のエディタとしての機能をもたらすコードは原則的には iframe の生成のたびに評価・実行されるということだ。コードは現状一万行以上あるわけで、これは大いにリソースの無駄だと思う。もちろん、ほとんどの場面でブラウザが持つコードキャッシュがそれをカバーしてくれるわけだけど、常にそうとは限らない。

これが、モデルとビューを分離するとどうなるか。エディタとしてのコードをバックエンド側に常住させることができるのだ。機能の区分けとしてはあくまでフロントエンドなので位置づけが難しい（フロントエンドのバックエンド側？）が wasavi が起動するたびにバックエンド側で

instances.push(new WasaviFrontend)

的に常駐しているコードからインスタンスを生成して割り当てれば、起動のたびに巨大なコード群を評価させる必要はなくなる。iframe 側が担当するのはキー入力の受付と、バックエンドへの送出、バックエンドから送られてくる再表示コマンド列の評価実行だけということになる。

以前、wasavi の設定を同期可能にするとして、どうしたものかというのを少し考えたことがあって、そのときは exrc に秘密の情報を書いている場合もあるかもしれないし、全自動で同期させるのはどうなのかということで棚上げにしていた。しかしじゃあ半自動ならいいのかというとそれはそれでなかなか使い勝手が悪そうだ。ということでやっぱり全自動でいいんじゃないのかなあという気分になりつつある。そもそも exrc に秘密の情報を書くことがあるだろうか。ない。

具体的には、現在は設定の保持にバックグラウンドの localStorage を使っているところを、例えば Chrome であれば chrome.storage.sync 系の API を使う。少し面倒なのは、localStorage であれば値の代入や読み出しは同期的に行えるのに対して chrome.storage は非同期的なのでその辺の修正は必要だという点。しかし実は下準備はすでにしてあって、バックグラウンドの初期化は Promise を使うようにしたので同期だろうが非同期だろうが特に問題はない。

Firefox はどうなのか。Firefox にも同期の仕組みはあるのだが、エクステンションに公開されたストレージ API というのはない感じ。少なくとも Add-on SDK にはない。そのかわり割と有名なテクニックとして about:config にリストされる Firefox 自身の設定のうち services.sync.prefs.sync.extensions. で始まるものは extensions. 以降の部分のキーが同期対象になるというものがある。

これ、同期が完了する前に読み出したりしたらどうなるんだろうか。Chrome の同期 API の場合は同期された値を読みだした時のコールバックを使用するわけなのだけど。Firefox ではどうなるの？　逆に同期完了前に値を設定したりしたらどうなるの？　わたしの救助信号とどいてるの？　Oh, 答えて。

issue #87。

たいていのフォームで textarea って最後の方（つまり、submit ボタンの近く）にあるから、[cci]:wq[/cci] でついでにサブミットしちゃえばいいんじゃね？　というアグレッシブな提案。

wq コマンドは非常に基本的なものなので、それによって便利になる web ページは随分あるだろうが、何もかもめちゃくちゃになる web ページも同じくらいあるだろう。

ということで wq にそういう機能を持たせるのではなく、新しいコマンドを新設する方向で考えている。例えば [cci]:wqs[/cci] (write-quite-submit) のような。

issue #37。

Linux というか X11 が動いている環境上での vim は [cci]*[/cci] レジスタと [cci]+[/cci] レジスタで PRIMARY セレクションと CLIPBOARD セレクションを使い分けるはずであるが、wasavi ではそうなっていないというもの。

とはいうものの、ブラウザのエクステンションから操作できるのは CLIPBOARD セレクションだけである。とりあえず [cci]*[/cci] だけでなく [cci]+[/cci] レジスタも有効なレジスタと見なし、[cci]*[/cci] のエイリアスとして扱うように修正。

wasavi が何らかのメッセージを出力する場合、いくつかの出口がある:

• バックログ・コンソール: 出力が複数行に及ぶ時に wasavi の画面全体を覆う形で表示される。モードは backlog_prompt に移行する。これは command や insert/overwrite などと同じレベルに位置する立派な vi のモードの一つだ。lastMessage は最終的にバックログの全内容を代入される
• ステータスラインの message: 出力が 1 行のみの場合は単にステータスラインにそれを表示し、モードは backlog_prompt へは移行しない。lastMessage は出力される 1 行そのものを代入される
• ステータスラインの notice: これは message とほとんど同じなのだが、lastMessage を更新する場合としない場合がある:
  • 通常の notice: ステータスラインに何らかの文字列を表示する。lastMessage は更新しない。これを使用するのは例えば、[cci]n[/cci] コマンドなどで現在使用している検索文字列をステータスラインに表示する時など
  • silent な notice: 内部的に何らかのメッセージは生成するが、表示はせず、エラーベルを鳴らす。lastMessage は更新する。これを使用するのは例えば、行頭・行末・テキスト戦闘・テキスト末尾を超える [cci]hjkl[/cci] 各コマンドなど
• lastMessage これは内部的な変数で、出力先にかかわらず出力した結果を保持する。機能テストの際にこれを参照する

ここで重要なのは、バックログと message は本質的に同じバッファを共有しなければいけないということと、message と notice の使い分けを正しく行わなければならないということなのだが。前者に関して徹底されていなかった（対症療法的な修正がたくさんコミットログに残ってて結構恥ずかしい）のでそのへんを見直して修正した。

後者は明確なルールがあるわけではない。ただ実際に使ってみた際にログが溜まりまくってうぜえ！的なものは notice、エラーメッセージ的なものは message に回すように見直した。

現在の常用のブラウザはここのところ Firefox beta だったのだが、例の「拡張は署名済みじゃないと入れさせませんぞー！」という仕様変更に対応するため Firefox Developer Edition に鞍替えすることにした。

ということで入れてみた。プロファイルも別扱いになるので、いくつかの設定はやり直す必要があるものの（フォントとか）、それ以外の設定は Sync 経由で復帰することができる。

若干気づいたこと。

• 全体的なテーマが黒基調になっているのだけど、黒い背景に微妙に色味の違う黒いテキストボックス…みたいに見難くて、色の選択が下手だ。ちゃんとしたデザイナーを雇ったほうがいいと思います
• cfx 経由で動かすと、browser.xul のパースエラーで起動しなくなる。起動時の xml パースエラー自体は過去にも存在したバグで、ローカライズド版で発生するらしい。それがまた発生したのか直してなかったのかわからないが、とりあえず [cci]LANG=C firefox[/cci] などとするとパースエラーは出ず起動する。まあ従来の Aurora を置き換えたのが Developer Edition だからね。この程度のバグは普通にたくさん包含しているのでしょう