すでに書いていると思うけれど、:script コマンドには 2 種類の書き方がある。:script の引数としてスクリプトコードを与える方法と、:scriptend までの間に記述する方法。前者を single-lined script、後者を multi-lined script としよう。

vim では、たとえば :lua と打つとその場で（つまり、コマンドライン入力モードのまま）スクリプトコード本体を打ち込めるようになっている。非常に賢い。でもそれを実装するのは面倒だなあ……。

というわけでとても乱暴なことに、wasavi 実行中に対話的に ex コマンドを入力するシーンでは :script は single-lined script のみ認めることにする。multi-lined script は exrc の実行、および :source でのみ有効となる（:source はまだ実装していないけど）。

　＊　＊　＊

とりあえず、:script を含んだ exrc をエラーなく実行できるようにした。Chrome や Firefox でも同様に実行できるようにした。

それにしても新しく書かなければならないコードが多すぎてさっぱり進んでいる感じがしない。

特に Chrome に対して重要な変更を施した。

wasavi が属する文書とスクリプトフレームが属する文書は、同一のオリジンである必要がある。これは、wasavi 側から scriptframe.contentWindow.dispatchEvent(ev) としたり、あるいは逆にスクリプトフレーム側から window.parent.dispatchEvent(ev); とするためだ。同一オリジンじゃないと dispatchEvent() は拒否される。dispatchEvent() を用いるのは、それが同期的に実行されるからで、postMessage() を使うといろいろと話がややこしくなる。

ところで Chrome では、wasavi が属する文書はエクステンション内のものにしていた。つまり chrome-extension://なんちゃら、という URL の文書。ところが、この URL に属する文書に付随するスクリプトは content script と同じ扱いになるのだった。この環境でスクリプトを動かすには、権限が高すぎる。

Opera や Firefox(Add-on SDK) では、エクステンション内の文書を通常のページの iframe の内容として表示することはできない（Firefox ではなにか方法はあると思うが調べてない）ので、appsweets.net 上の文書を参照している。これなら、スクリプトを動かす際に一般の web ページの権限が適用される。

ということで、Chrome でもその流儀に従うようにした。これは manifest の変更を意味する。ただしより強い権限を要求するのではなくその逆で、web_accessible_resources が不要になる。しかし一方でコンテキストメニューのために permissions に contextMenus を追加したので、次のリリースをインストールする際にはなにがしかのダイアログは出るはず。

ちなみに Chrome の不思議な特性として、コンテントスクリプトから、コンテントスクリプトの影響下にない素の Window オブジェクトにアクセスすることができない。つまり scriptframe.contentWindow を触れない。そういうわけなので、wasavi 側の文書で script 要素を生成し、以下のコードを text 属性に突っ込む:


document.addEventListener('WasaviScriptRequest', function (e) {
var ev = document.createEvent('CustomEvent');
ev.initCustomEvent('WasaviScriptRequest', false, false, e.detail);
document.getElementById('wasavi_script').contentWindow.dispatchEvent(ev);
}, false);


で、wasavi 側からスクリプトを呼び出す際は自らの文書に対してイベント起こす:


var ev = document.createEvent('CustomEvent');
ev.initCustomEvent('WasaviScriptRequest', false, false, {code:"console.log('hello, world')"});
document.dispatchEvent(ev);


スクリプトの環境では、window.wasavi オブジェクトが事前に定義されていて、それを通して wasavi を操作する。たとえば wasavi.run(‘Ihello, world\u001b’); のような。

ここで面倒なのは、wasavi のコマンドの中には非同期に実行されるものがいくつかあるということだ。たとえばクリップボードレジスタを参照する場合や、:read、:edit など。スクリプトから呼び出す際は、これらのコマンドも同期的に動作させなければならない。そうしないと

wasavi.run(':r foo.txt\n');
wasavi.run(':Iwow!\u001b');

と言ったスクリプトが正しく動作しない。

とは言ったもののこれはかなり難しい。非同期的な処理を同期的に扱うのは、やはり ES6 の generators が欲しい。しかし generators を現時点で実装しているブラウザはないのだった。正確に言えば、Firefox は javascript 1.8 としての generators は実装しているが微妙に仕様が違う。Chrome は canary と dev で chrome://flags を操作することで試験的に使うことができる。Opera は……まあ Opera だからね！

ということで、スクリプトの機構は作っておき、さらにシンタックスハイライティングの定義をするインターフェースも作るが、wasavi に対してコマンド列を送る機能は各ブラウザに generators が実装されるまでおあずけということになると思う。

ES6 っていつ策定完了するのかなあ？

ぼちぼち実装し始める。

とりあえずスクリプトフレームを起動時に生成するようにした。ついでに、appsweets.net ドメインのコンテンツを Application Cache に入れるようにした。

スクリプトフレームで動く injected script を新設した。中味は後で書く。

ex コマンドのパーサに手を入れた。script コマンドが入力された場合、「リテラルモード」に入るようにした。ただし、script コマンドの引数が与えられていた場合はリテラルモードには入らない。つまり

:script foo();

と

:script
foo();
:scriptend

という 2 種類の記述方法が使えることになる。vim では、:lua や :ruby はヒアドキュメントっぽい記述方法になっているが、それは別に踏襲しない。リテラルモードを終了させるのは行がまさに “scriptend” である場合だ。なお、scriptend が現れないままソースコードの最終行までパースした場合、自動的に scriptend が補完されたような動作をする。つまり ex コマンド列の最後のコマンドが script であった場合は、scriptend は書かなくてもよい。

ex コマンドに script を新設。ちなみに、スクリプト関連としてはこの他に

• source: スクリプトファイルを読み込み、実行
• listen: イベントにスクリプトを登録する。vim で言うところの autocmd
• unlisten: イベントからスクリプトを削除する。vim で言うところの autocmd!
• command: 任意のスクリプトコード塊に名前を付け、ex コマンドとして認識させる。vim の同名コマンドと同じ

あたりが必要だと思う。:source のスクリプトファイルというのは、エクステンションの localStorage に擬似的なファイルシステムを構築することになるだろうか。このへんは Opera Unite みたいにローカルファイルシステムの特定の場所にマップする仕組みがあるととてもいいのだけど。

あとは、script コマンドのハンドラ内で実際にスクリプトフレームへスクリプトコードを投げつけ実行させる処理を書く。

一方で、スクリプト側から wasavi を制御する場面を考えると、まずスクリプトを実行させる場所になる iframe（以下スクリプトフレーム）で最初に wasavi オブジェクトを定義し、それを通してアクセスさせる。

アクセスの手段は

• run: コマンド列の送信
• rows: 任意の行の読み書き
• options: オプションの読み書き
• registers: レジスタの読み書き
• marks: マークの読み書き

あたりがあればいいと思う。

ところで面倒なことがある: スクリプトフレームは wasavi 本体とは異なるドメイン上の文書として存在させたい。これはスクリプトから wasavi の DOM とかを直接いじられたくないからなのだが、そうするとスクリプトと wasavi とのやりとりはクロスドメインメッセージングを通して行うことになる。つまり非同期ということになる。うーん。これはちょっといまいちなんじゃないか。複数回コマンドを発行するだけでも


wasavi.run('Ihello, world\u001b', function () {
wasavi.run('0cwbye\u001b');
});


みたいなネストしまくりコールバック地獄になってしまう。Deferred 的なライブラリを用意するのもちょっと根本的な解決とはいえない。それよりも同期式のほうがずっと単純でわかりやすい。generators が各ブラウザに実装されればなんとかなるんだけど。harmony に generators って入ってるんだっけ？　調べたら function* foo () {…} みたいな形で作るようになってるのか。早く実装されないかなー。

で、それを待ってもいられないので、仕方ないのでスクリプトフレームも wasavi と同じドメインの文書ということにして、もう window.parent 使って直接読み書きするしかないかもしれない。とりあえず元の window.parent はスクリプト上の wasavi オブジェクト内に閉じ込めて、スクリプトからは隠す的なことはすると思う。他に親フレームにアクセスする手段ってあったかな。多分なんかある。

もうちょっとスクリプティングについて整理してみよう。

• なぜスクリプティングが必要なのか？
  ユーザに wasavi の動作を好きにさせるため
• どのような動作をスクリプタブルにするのか？
  バッファへの読み込みの前後、書き込みの前後、モード変更の前後、オプションの変更時などでイベントを発生させ、各タイミングでユーザ定義のスクリプトを実行させる。スクリプト内で、wasavi に対してなにがしかの動作を行わせるようにする。また、ex コマンドに :script（スクリプトの定義と実行）、および vim で言うところの :command を追加する。
• スクリプトの言語は何か？
  javascript。javascript でやるとすると、なんでもやり放題というふうにはさせないようにしなければならないのと、同期・非同期のことを考える必要がある。前者は sandbox な iframe 内で実行させるようにすればいいかもしれない。例によって Opera だけ sandbox にまだ対応していないが、まあこれは html5 の仕様なのでいずれ実装される。されたらいいな。

  後者は難しい。スクリプトの呼び出し自体を同期的にするか、非同期的にするか？　また、スクリプトに対しては wasavi を操作するインターフェースを公開することになるのだが、スクリプトからの wasavi の呼び出しもまた同期的なのか、非同期的なのかを考える必要がある。

  まずスクリプト自体の呼び出しだが、これは両方サポートする必要があると思う。バッファを編集するコマンドとして定義したスクリプトは、シーケンシャルに実行されないと辻褄が合わなくなる。一方、たとえば XHR を利用して何処かに何かを通知するようなスクリプトは、別にサーバの応答をその場で待つ必要もないだろう。そういうわけで両方必要。

  呼び出し方。:script コマンドにスクリプトのソースを引数として与えて
  
:script foo();

  あるいは :script と :scriptend コマンドのペアの間に記述して
  
:script async
function foo () {
wasavi.run('Ihello, world\u001b');
}
foo();
:scriptend

  みたいな感じか。デフォルトは同期呼び出しで、:script の最初の引数が “async” だったら非同期スクリプトとして呼び出す……みたいな。いやダメだな。非同期として設計されたスクリプトを同期設計のつもりで呼び出したり、その逆が起こりうる。スクリプト自身が動作を表明した方がいい。
  
:script
wasavi.async = true;
function foo () {
;
}
foo();
:scriptend

  こんな感じか。

だいたいイメージが固まってきたかな！

次に実装すべきものの中で大きなものを考えると、シンタックスハイライトとスクリプティングだと思う。

さてこの 2 つのうちではどちらに手を付けたものだろうか？

シンタックスハイライトについては、2 つの考える必要がある点があると思う。どのように色分けを実装するか、そしてシンタックスをどう動的に定義できるようにするか。前者は、それで閉じている問題だが、後者はスクリプティングの仕様と絡んでくる。

と、いうことは、スクリプティングを先に考えたほうがいいのかもしれない。イメージしているのは、vimscript のように ex コマンドを盛大に拡張する感じのものなのだけど、ただ vimscript はあんまり好きじゃない。編集のための ex コマンドと vimscript で呼ぶための関数及び if とか try とかの制御構文が、何もかもごちゃまぜなのが好きじゃない。ex コマンドの仕組みを間借りしてスクリプトを実行するとしても、両者ははっきり区別したほうがいいんじゃないかしらん。まぜこぜになってるメリットがよくわからない。

html ファイル内の script 要素のように、スクリプト開始コマンド・終了コマンドを設けて、その間にスクリプトを書くようにしてはどうか？


:script
function foo () {
;
}
:scriptend


みたいな感じで、scriptend コマンドによってスクリプトが評価・実行される。ところで思わずそのスクリプトを javascript 的な言語で書いてしまったが、どうするか。javascript が無難かなあ。オレオレ言語をぶちあげてコンパイラと VM を書く元気はない。しかし素の javascript の実行を許すと、なんでも出来すぎるのがまずい気もする。

うーん悩むなあ。

編集済みフラグというものがある。何かバッファに編集を施すとオンになる。:write で保存するとフラグが降りる。それから、undo/redo するとフラグが適宜変更される。

そういった機能をつける。前 2 者は全くめんどくさくないのだが、難しいのは undo/redo との絡みだ。

編集済みフラグとはつまり、ディスク（wasavi では対象の textarea）の内容と差異があるかどうかということだ。保存をした時点での undo バッファの最後のアイテムを参照する変数を用意する（saveAt 変数）。undo/redo すると、内部的な undo バッファのインデックスが変化する。saveAt と undo バッファのインデックスが指すアイテムが同じであれば、差異はない状態。同じでなければ保存前の状態に戻っている・あるいは保存後編集を加えている、どちらも含めて差異がある状態と判断できる。

というわけでそういうふうに組んだ。vim 同様、ステータスラインのファイル名のおしりに、差異があれば “[+]” と表示するようにした。

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 を再起動すると直る。直らなかったりする。やめてよねそういうの！