expandtab #3

vim が持つ expandtab 絡みのさまざまなオプションであるが、とりあえず wasavi には expandtab オプション以外は実装しない。つまり smarttab と softtabstop は実装しない(tabstop、shiftwidth はすでに実装してある)。

で、実際に input モードで tab キーを押した際になにが起こるのかをまとめると:

  1. タブ(U+0009)をカーソル位置に挿入する
  2. 行頭のインデント中のタブを一旦すべて空白に置き換える
  3. 行頭のインデント中のマークをすべて退避する
  4. expandtab がオンなら、何もしない。オフなら、行頭のインデントを先頭から走査して、タブに置き換えられる箇所を置き換える。つまり tabstop の字数ぶん連続した U+0020 を U+0009 に置き換える。その過程で、退避したマークのオフセットのつじつま合わせも行う
  5. 退避したマークを再設定する

という感じになる。実はこの処理の大部分は、シフトコマンドのそれである。なのでまずその辺を詰めることになる。例えば tab キーを押した際の処理は左や右へシフトを行うわけではない。いわば 0 カウントだけシフトすることになる。という訳でそんな感じのいろいろな修正を施した。

expandtab #2

もう少し整理してみる。

vim で input モードで tab キーを押した時に、まず以下のオプションが参照される:

  • tabstop
  • expandtab

tab とスペースの変換という点で見ると、この 2 つがコアになる。tabstop は tab が最大何文字幅分に伸びるかを指定する。expandtab は、tab キーを押した際に対応する文字数分の空白に置き換えるか、および行頭インデントの最小化(つまり、空白を可能ならタブに置き換える処理)をスキップするかを指定する。

一方で、本質的ではない以下のオプションも参照される:

  • softtabstop
  • shiftwidth
  • smarttab

softtabstop は、「タブ幅は標準の 8 桁から変えたくないけど、インデントの単位は 8 じゃない数値にしたい!!」という向きに応えるためにある。タブ幅自体を変えても気にしないなら、このオプションを弄る必要はない。

shiftwidth は、本来は、< と > コマンドによってシフトする際のシフト量を指定するためのものだが、smarttab の状態によっては tab キー押下時に参照されるときがある。

smarttab は、インデント量をカーソルの位置に応じた文脈で選択させるようにする。smarttab がオンの状態で、カーソルが行頭のインデント領域の中にある時、shiftwidth の分だけインデントされる。smtarttab がオフであるか、あるいはオンであってもカーソルが行頭インデントではない箇所にある場合は、softtabstop、tabstop の順に評価して 0 ではない最初の値を取り出し、それをインデント量とする。

とこのように、expandtab 自体は単純明快なのだけど。字下げスタイルという個々人の好みにものすごく左右されるものにできるだけ対応するための、付加的なオプションのおかげで全体的になんだかわよくわからないものになってしまっている。

さらに cpoptions オプションの設定によって微妙に部分的な動作が変わったり、あるいは前の記事の通り backspace オプションが絡んできたり、:retab コマンドの動作にも影響したりする。カオスすぎる。

expandtab

issue #16 の、vim の expandtab を実装してよというリクエスト。

expandtab がオンの状態だと、input モードで tab を押した際、タブそのものではなくタブ幅に応じた適当な個数の空白が挿入される。また、> や < でシフトした際、通常はタブで置き換えられるなら置き換える(つまり ts=8 で sw=4 の状態で 2 回シフトすると、インデントは 1 個のタブになる)のだが、その処理を迂回して常に空白でインデントするようになる。

他にも影響があるところがあるかも知れない。実は個人的にこのオプション使ったことがないので、よくわかっていないのだった。インデントを常に空白で行うというのはなんというか富豪的である。貧乏人は普通にタブを使うのだ。

また、間接的に backspace オプション、retab コマンドとも関連する。これらとセットじゃないとやはり実用上は辛いかもしれない。というわけでフルに実装するとけっこうかなり面倒な代物なのだった。

ということを issues やりとりしたら、とりあえず単にインデントを空白で行う処理だけでもいいんじゃね? みたいな話でまとまったので、そういう方向でやってみよう。

coexistence with CodeMirror #2

CodeMirror 上で wasavi を起動できるようにした。また、ace でも同じように特別な対応を施すようにした。

ただ、若干もったいない話ではある。CodeMirror も ace も、それ自体が高機能なエディタなのだ。また、両者とも vi っぽいキーバインドにすることができる(ex コマンドっぽいものはない)。

coexistence with CodeMirror

github 上の issue についていくつか。

#18
sqlfiddle というサイトで wasavi がうまく起動しないというもの。このサイトでは、ページ上に CodeMirror を置いている。

CodeMirror 自体が javascript と DOM と css からなる複雑な要素で構築されたテキストエディタである。一方で wasavi はシンプルな textarea に対して起動する。したがって両者の相性はそもそも良くない。CodeMirror の実行中に ctrl+enter を押すと一応 wasavi が起動するが、これはたまたま現在の CodeMirror がキーボード入力を受け付けるために隠された textarea 要素を抱えているだけの話だ。起動しても、編集中のテキストが正しく wasavi に転送されるわけでもあるいは逆に書き出せるわけでもない。

なので、単にサポート外ですと言ってもいいのだけど、なんとかならないものなのだろうか?

CodeMirror を構成するオブジェクトとしては、

  • 置き換え先の textarea 要素: CodeMirror がアクティブな間は display:none されている
  • CodeMirror の DOM 上の表現: “CodeMirror” をクラス名に含んだ div 要素
  • javascript 上の CodeMirror インスタンス

がある。wasavi の content script/injected script から、最後の CodeMirror インスタンスにアクセスできればなんとかなる。

実はこのインスタンスは div.CodeMirror 要素から参照できる。なのでページ上の javascript からは、

document.querySelector("div.CodeMirror").CodeMirror.getValue()

などとすれば CodeMirror が保持するテキスト全体を得ることはできる。しかし content script からは、参照している window が別だったりラップされていたりするのでこの方法は使えない(Opera ではできるが、inject script のコンテキストからページ上のスクリプトが生成したオブジェクトを直接呼び出すのは怖いのでやりたくない)。

wasavi が置き換える対象となる要素に対して内容を読み出したり書き込んだりする機構を汎用化してページのスクリプトのコンテキストを通すようにすればいいかもしれない。

When I overwrite a directory as a file…

wasavi を起動し、dropbox や gdrive にすでにディレクトリとして保存されているパスに対して :write した場合、エラーになってもらわないと困る。もしも保存したパスがディレクトリで、なおかつそのディレクトリの下に多数のファイルが保持されている時、有無を言わさずそれらがすべて消去され指定のパスが同名の単なるファイルにすり替えられるとしたら、これは絶対に避けなければならないケースだ。

google drive の場合、ファイルを上書きするには先んじてそのファイルの ID を得なければならない。これはこれで面倒な作業ではあるけれど、しかしその過程でファイルの mime タイプが application/vnd.google-apps.folder かどうかを判断するチャンスがアプリケーション側に与えられるので問題ない(それを一つのトランザクションとして見なした場合、そんなゆるゆるなチェック体制でいいのか? とは思うけど)。

dropbox の場合、ファイルを更新するにはそのパスと内容を同時にアップロードするだけだ。dropbox で上記のクリティカルなケースがどうなるか試してみたところ、どうもサブディレクトリの下にファイルがある場合はエラーになり、完全に空のディレクトリの場合は単なるファイルへの上書きが成功するようだ。

それはそれで賢い振る舞いなのかもしれない。また、この辺の振る舞いは別に wasavi 側で規定できるわけでもない。

ということで、そういう動きを受け入れることにする。

picking up the locale

Presto Opera のエクステンションにおいて、エクステンション内のファイルを xhr なりなんなりで読み出した場合、先んじて /locales/[現在のロケール]/[指定されたファイル] というパスが検査され、そこにファイルがあれば優先して使用されるようになっている。この仕組みをもって、i18n に対応してます! と Opera は嘯いている。

このとき、[現在のロケール] とは具体的には何なのか。たとえば Opera の設定で UI のロケールを変更しても、エクステンションの上記の仕組みには影響しないようだ。

コンピュータにログインした状態では、だいたい

  • システムのロケール
  • ログインしたユーザのロケール
  • 実行したアプリケーションのロケール
  • Opera の設定: UI のロケール、accept-language に送出するロケール

みたいな階層構造でロケールが定義されると思う。Presto Opera のエクステンションでは、どうも最後の UI ロケールは見ていないような気がする。このように、エクステンションのロケールを気軽に切り替えられないのは特にテストの時に不便だ。というのは、テストは en-us ロケールで実行するのが前提だからだ。Chrome はコマンドラインのオプションでロケールを指定できる、あるいは Firefox はプロファイルに設定したロケールが Add on SDK のロケールモジュールにも正しく影響するので問題ないのだけど、Opera だけがポンコツだ。

というわけで、Opera ネイティブの i18n システムをそのまま利用するのではなく、navigator の browserLanguage/language/userLanguage あたりを見て自前でロケールを決定するようにした。

つまり結局のところ Opera ネイティブの i18n システムは利用しないことになった。用意されてる機能がポンコツ過ぎて役に立たないというのは、まあ Opera においてはよくある話なのであります。

Selenium revised #3

仮想環境の Ubuntu 内でビルドとテストが行えるようにした。とりあえず chrome でテストが実行できることを確認したけど、なんか、仮想環境というのを差し引いてもちょっと遅い。全テストに 110 分くらいかかる。その他いろいろ微妙にテスト時の chromium の動きが Windows 上の chrome と違う部分がなくもない。

ついでに javascript の minifier として UglifyJS2 を使ってみた。

Selenium revised #2

以前書いた通り、wasavi をテストする Selenium の構成は

  • Selenium server
  • Selenium client (java)
  • junit
  • chromedriver
  • operadriver

といった感じで、それぞれの jar あるいは exe を必要とする。テストを java で書くのは wasavi のビルドを ant に頼っていて、また ant から junit のテストを呼び出すのが簡単だからだ。

chrome
chrome の場合は chromedriver.exe というものが chrome と Selenium の間に立つブリッジになる。これを最新のもので更新したところ、いきなり動かなくなった。というのは、テスト用に立ち上げた chrome に wasavi が読み込まれないのである。この場合の wasavi は、開発者モードとして読み込まれる必要がある。これはつまりエクステンションのアーカイブではなく、ファイルシステム上のソースをそのまま参照してねモードだ。このモードを指定するには、chrome の起動時のコマンドラインオプションで [cci]–load-extension=C:/path/to/extension[/cci] てな感じのを追加する。

で、それがどうやら効いていないようなのだ。テスト用に立ち上げた chrome で chrome://version を開いてコマンドラインを参照してみると、wasavi 以外に selenium とのやりとりのためのエクステンションが指定されている。どうやらこれと競合しているらしい。–load-extension って複数指定できないんだっけ。

というわけで、テスト用 chrome に対してプロファイルディレクトリを明示して指定するようにして([cci]–user-data-dir=C:/path/to/profile[/cci])、そのプロファイルに対して予め開発者モードの wasavi を登録しておくようにした。

その他は特に問題なし。

opera
opera の場合、operadriver.jar が opera と Selenium の間を取り持つ。operadriver.jar は Selenium client に付属しているので、基本的には別途取得する必要はない、のだけど。たとえば Selenium 2.35.0 に付属の operadriver-1.4.jar だと、うまく opera 12.16 が起動してくれない。数日前にリリースされた operadriver-1.5.jar を代わりに使う必要がある。

このように、Selenium とブラウザと付随するライブラリのそれぞれのバージョンによって動いたり動かなかったり、一部の機能が動かなかったりすることがけっこう多い。これは困ったものです。特に最近のブラウザはえらい勢いでバージョンが上がるので、なおのことその危険性は高い。

ブラウザのオートメーションというものは、このようになんだかずいぶん脆弱な仕組みの上にかろうじて成り立っているように思える。この辺りの動作こそブラウザベンダ同士が協働して仕様やプロトコルをきっちり決めたらいいんじゃなかろうか。

ちなみに opera の場合もプロファイルを明示して、そのプロファイルに対して開発者モードの wasavi を登録しておく必要がある。

firefox
firefox については特別な jar ファイルとかは必要ないのだけど、その代わりなんか動作が変だ。たとえば shift キーとかのモディファイアを指定したキーストロークを送出することができない。wasavi は起動するためにデフォルトで ctrl+enter のショートカットを使うので、これはなかなか致命傷なのである。

あと、全体的に遅い。chrome で全テストを終えるのにだいたい 1 時間かかるのだけど、firefox で行うとだいたい 1.5 倍くらいの時間がかかる。

また、firefox にはエクステンションを開発者モードで読み込む的な機能がない(知らないだけであるのかもしれないが)ので、テスト前に一旦アーカイブをビルドする必要があるのが地味に面倒くさい。

 * * *

というわけで一応 3 ブラウザでテストを行えるようにはなりつつあるのだけど、実行時間が問題だ。先に chrome でさえテストに 1 時間かかると書いたが、これはすべてのテストをシーケンシャルに行っているからだ。テスト自体は編集のテストとか、ex コマンドのテストとか機能毎に独立したソースになっているので、すべてを並列にとは言わないが、せめて同時に 3 枚くらいウィンドウ出して並行して行えばスピードアップできるのである。そんな機能ないのかなー。

また特に firefox の場合、テスト用に立ち上がる firefox が必ずフォアグラウンドな状態じゃないとテストが失敗するという意味の分からない動作をする。つまりテストの間 pc はそれに専念する専用マシンと化してしまうのだ。

なに、それ。テスト専用 pc を複数用意しろというのか。

Selenium revised

Firefox 版の wasavi を AMO にフルレビューしてくれと提出してもう 2 ヶ月くらい経つのだが、キャンセルした。というのはあまりにレビューが遅いからではなくて、なんとびっくりすることに Firefox 版の 0.5.329 では http://wasavi.appsweets.net/ を開いた時に自動的に wasavi が起動する機能がバグってて動かなかったのだ。

これはかなり恥ずかしい。wasavi をリリースする前準備として、Selenium を通した機能テストを行っている。666 項目のテストをパスしてからリリースするのである。といっても、実を言うと、そのテストは Chrome だけでしか通していないのであった。Opera と Firefox は通していない。

これは、wasavi の仕組みのせいなのか、Selenium の制限なのか、Selenium と Opera/Firefox をつなげるブリッジ部分のドライバの制限なのかよく分からないが、とにかく Opera と Firefox で動かすと wasavi をそもそも自動起動させられなかったり、キー入力が無視されたりしてテストにならなかったのだ。Chrome だけが素直にテストが通る。

しかしそういうわけにもいかない。3 ブラウザで完全にテストを通すようにしないといけない。そういうわけで Selenium のテストを見直すことにしよう。