たとえば
foo
bar
foo
bar
foo
bar
foo
bar
foo
bar
という 10 行のテキストがあり、カーソルは最終行にあったとき、テキスト全体をコピーして末尾にペーストしたいとする。
vi コマンドであれば、[cci]ggyGGp[/cci] で 6 手である。ex コマンドにおいても [cci]:1,t.
ところで [cci]:%t.
たとえば
foo
bar
foo
bar
foo
bar
foo
bar
foo
bar
という 10 行のテキストがあり、カーソルは最終行にあったとき、テキスト全体をコピーして末尾にペーストしたいとする。
vi コマンドであれば、[cci]ggyGGp[/cci] で 6 手である。ex コマンドにおいても [cci]:1,t.
ところで [cci]:%t.
Dropbox側の修正を終えたのでテストしてみたところGoogle Driveに対する読み書きでコケる。なんで?
OAuth2による認証が成功した直後、自身のプロファイル情報を得るAPIを呼び、認証に成功したIDと一致することを確認している。Google Driveの場合は、
https://www.googleapis.com/oauth2/v1/userinfo
に対してPOSTして返ってくるjsonを参照している。このエンドポイントが404を返すようになった。11日前にwasaviをリリースした際にはもちろんすべてのテストが通ったことを確認してあるので、その間になんか変わったようだ。
Googleが提供するAPIの包括的なリファレンスというのは、どこにあるのかよくわからない。しかしAPI Explorerというものがあり、実質的にここでAPIの仕様を確認できる。ということで Google OAuth2 API v2 を見てみると確かにuserinfoはない。その代わりoauth2.userinfo.v2.me.getというものがあるのでこれがどうも最新のようだ。エンドポイントは
https://www.googleapis.com/userinfo/v2/me
だ。これにどのフィールドを参照するかのクエリ文字列(今回の場合は[cci]?fields=id[/cci])を付加して、GETで取得すると結果が返ってくる。
API Explorerで参照できるAPI名らしきものとエンドポイントのURLの構造が微妙に似ているような似てないような感じになっているのは何なんだろう。わからん。それと、この最新のAPIを使ったとしても、POSTだとやはり404が返される。ちゃんと書いてあるとおりにGETじゃないといけない。
去年からさんざんアナウンスされつつも、夏休みの宿題のノリでまあ切羽詰まったらやればいいだろう…と思っていた、Dropbox の API が v1 から v2 に移行するというトピックにそろそろ対応したい。
移行のガイドとしてはこんな文書がある。そのとおりに進めればいいはずだ。たぶんきっと。
幸いなことに、wasaviがDropboxを始めとしたオンラインストレージとやり取りする際に使用するAPIはそれほど多くはない。
てな感じなので順番に片付けていこう。まず認証に関しては単にエンドポイントが変わるだけなのでこれには問題はない。そして残りは全部面倒くさい。
ディレクトリの列挙。v1では、任意のディレクトリに対して[cci]metadata[/cci]APIをlistオプション付きで呼ぶと、そのディレクトリ自身のメタデータと併せて、一緒に直接の子供のメタデータのリストも得ることができた。ガイドによればこのAPIのv2における代替は[cci]files/get_metadata[/cci]なのだが。しかしlistオプション付きの場合はそれではまったく代替になり得なく、複数のAPIを組み合わせて使わなければならない。困ったことにこの辺はガイドにはさっぱり解説されていない。というわけでv1のlistオプション付きmetadata APIの代替になる処理を自前で書かざるを得ない。
まず任意のディレクトリ自身のメタデータを読み込むために、[cci]files/get_metadata[/cci]を呼ぶ。それが完了したら(ここは別に並列でもいいが)[cci]files/list_folder[/cci]を呼び子供のメタデータを得る。また、このAPIは一度に返される結果セットのサイズが決まっているようで、その呼び出しが結果セット全体の最後かどうかは不定だ。そのかわり呼び出しのたび最後の結果かを示すフラグ has_more を返すので、つまりこの後呼び出し側が責任を持って[cci]files/list_folder/continue[/cci]を複数回呼び出す必要がある。それから列挙対象のパスなどを与える方法が若干面倒でContent-Typeを[cci]application/x-www-form-urlencoded[/cci]ではなく[cci]application/json[/cci]にした上でJSONをPOSTしなければいけない。
なんだこれは。バージョンが進んだのにクライアント側でやらないといけない仕事が格段に増えている。ここまでの遷移を見てみると、個々のAPIができることがより制限され、かつその代替がよく解説されないという状況にしか見えない。どうにもいまいちだと言わざるを得ない。
ファイルの読み込み。[cci]files/download[/cci] を呼ぶのだが、読み込み対象のパスなどを与える方法が若干面倒。POST のボディではなく、[cci]Dropbox-API-Arg[/cci]なるヘッダに、JSONを文字列化したものを与える必要がある。それができない場合は、クエリ文字列として[cci]?arg=
ファイルの書き込みにおける変更点は読み込みと同じ。v1では書き込みの際はPUTメソッドを使用した。これはこれで筋が通っている仕様だと思うけど、v2ではPOSTに変更されている。
というわけでAPIの使い勝手としてはv1のほうが勝ってたんじゃないかなあ…と思わなくもない。
それから、v1では多くのパラメータに汎用的に[cci]locale[/cci]を付加することができたがv2ではHTTPのヘッダ(Dropbox-Locale)に含めるように変更になったとか、全てのアクセスはPOSTメソッドでないと「いけない」(GETも受け付けるとかではない)などの細かな変更もある。メソッドはともかく、ロケールは難しい。前述の通りXHRでは任意のリクエストヘッダを送出できるわけではないからだ。X-Dropbox-Locale とかなら送れるんだけどなー。まあロケールは主にエラーメッセージとかに影響するはずなのでそれほど困るわけではないのだけど。
[cci]s[/cci]コマンド中にバックスラッシュによるエスケープシーケンスを含んだコンポーネントを含めると正しく引数が解析されないのを修正。
つまり、[cci]:%s/$/ \\/g[/cci] みたいなのが正しく動作しなかった。
そろそろ各ブラウザの公式エクステンションストアに置いてるwasaviをアップデートする頃合いだ。
* * *
アップデートした。今年はこまめにストア版もアップデートするようにがんばるぞい。
wasaviはtextareaの他にcontenteditable属性の付いた要素も編集できるわけだが、そういう要素にどのように中身を埋めていくかはサイトによって異なり、統一されたものはない。そういうわけで、writeasというオプションを用意している。これには以下の値を割り当てられる:
issue #156でこの割当をサイトごとにできないかという要望があった。なるほど確かにそのほうがいいだろう。同様にサイトごとに動作を割り当てられる設定としては、wasaviの起動をさせないためのブラックリストがすでにある。こちらはさらにサイトの下にCSSセレクタを指定できるようにしてあり、個別の要素のレベルで制御が可能だ。writeasもそのようにすべきだろう。
具体的にはwriteasに対して上記の値の他に、JSONとしてパース可能な文字列を与えることを許す。このJSONは例えば:
{
"http://example.com/*": "div",
"http://example.net/*": [
{
"selector": "#element-id",
"writeas": "textAndBreak"
}
]
}
と言った感じの連想配列になり、URLに対するwriteasの値、あるいはURLおよびセレクタに合致する箇所のwriteasの値が取られる。
ところで、ブラックリストはwasaviのオプションではなくwasaviの起動前の設定である。この区別はとても重要だ。本質的にwasaviの設定はwasaviのsetコマンドから操作できるのが望ましい。そういうわけに行かないものだけが起動前設定として独立されるべきである。起動前の設定というのは他にexrcや、起動ショートカットや、起動時の効果音などだがこれはまさにwasaviが起動する前に処理される事柄なのでwasaviの設定からは「止むを得ず」独立させてあるということだ。それ以外の設定、つまりwasaviが起動した後に参照される設定はすべてwasaviのオプションにしてある。とこのように厳密に区別しているのである。さて今回の変更を施す場合、URLごとのリストという点ではブラックリストと似たものになるのだが、しかしいつ参照されるのか? という点で考えるとwriteasは依然としてwasaviのオプションだ。そういうわけで独立した設定にはしない。
ということは、上記のようなJSONをwriteasに代入する際は
set writeas='{ \
"http://example.com/*": "div", \
"http://example.net/*": [ \
{ \
"selector": "#element-id", \
"writeas": "textAndBreak" \
} \
] \
}'
という感じのexコマンドになるのだが、これはこれで改行のエスケープがすごく冗長だ。これはちょっと何とかしたい…。
viにはlistオプションというものがあり、それをオンにすると
となる。この内、行末尾の表示について実装したい。残念ながら、タブ文字の代替表示は難しい。
ここで行末尾を示すために文字 [cci]$[/cci] が用いられるというのは、vi が端末上のテキストエディタだからで、wasavi の場合はもうちょっと表現力があるので別の記号にしたい。
行末尾、つまり改行を示すための記号というとまあだいたいこんな感じだと思う。特に日本産のエディタでこれじゃない奴はないのではなかろうか。あと、MS Word。海外産だと行をパラグラフとみなして、Pilcrowが多いかもしれない。まあどちらでもいいけれど、とりあえず前者を使うことにしよう。
ところで、改行マークを表示することに意味があるとは特に思えない。それが役に立つのは、行末に余計な空白文字を残している、いわばダーティというか、非正規な状態の行を目視で確認したい場合くらいだろう。そういう行を正規化したいのなら目視確認なんてせずに正規表現による全置換すればいいだけの話で、改行マークを表示することに意味はない。また、正規化済みの行は空白ではないグリフの直後に改行があることが自明なわけで改行マークを表示する必要はなく、非正規な状態の行だけその旨を表示するようにすればいいのだが、非正規な行の場合でも本来強調表示すべきは行末の余計な空白文字であって、改行マークではない(vimの場合で言えばlistcharsに対してeolではなくtailだけ設定した状態)。従っていずれの場合でも改行マークを表示しなければならない積極的な理由はないように思える。
と、そう考えればそうなのだが、実は去年はあんまりwasaviの開発を進められなかったのでいまいち内部の構造を忘れかけているのであった。そのリハビリのためにあえて実装してみる。
ということでこうなった。
qeema 内でデグレードしてた箇所があったのを修正。Chrome で、IME がオンの状態でスペースキーを押すと(設定によっては)いわゆる全角スペース(U+3000、IDEOGRAPHIC SPACE)が直接入力されるわけだが、それが wasavi に正しく伝達されなくなっていた。
この全角スペースの直接入力に対して Chrome が発生させるキーボードイベントは実におかしい。
という感じに実におかしい。Firefox であれば正しく Composition Events が発生する。IME まわりは Firefox の方が Chrome よりずっと真っ当だ。
対応策として、input 内でなんとかするしかなく、実際そうしている。keydown でその時点での対象の要素の値を保存しておき、input で差分を取ってイベントを生成させる。デグレードしたのはその処理が正しく呼ばれていなかった。
ところで Opera ではどうなのだろうか。Blink Opera でも operadriver というものを経由してテストすることになっている。これはつまりchromedriver のフォークだ。じゃあ、だいたい Chrome のように動くと考えていいのかな。
と思ってやってみたらまるでさっぱり動かない。Opera 自体は起動するものの、
exception: Error: ECONNREFUSED connect ECONNREFUSED 127.0.0.1:46266
なる例外が発生してテストが始まらない。
Selenium のライブラリと *driver との接続は http による REST だ。つまり、operadriver 側でリモートコントロールのための接続の listen をしてくれないということなのか?
とそういうわけで現在のところの各ブラウザの selenium 対応は Chrome、Firefox、Opera の順で甲乙丙のようだ。
そういうわけで Linux 上では WebExtensions 版の wasavi の、Selenium による、Firefox 上の機能テストを一通り通せるようになったのだが、結局これを Windows 上ではできていない。過去の記事で何度か書いているが Windows では既存のプロファイルでもって Firefox を起動させることができず、かつ新規プロファイルに WebExtensions ベースの拡張を登録させつつ Firefox を起動させることもできない。両方できないと身動きが取れない。
実を言うと Linux 上でもテストが問題なく滞りなくできてるわけではない。例えば:
(node) warning: possible EventEmitter memory leak detected. 11 listeners added.
前述のプロファイル関連の不具合と合わせて、どーにもこーにも…… Firefox が絡む Selenium のテスト環境はいつも質が悪い、質が低いと言わざるを得ない。どうなってんのかなあこれ……。この辺が快適になってくれないと、Firefox 向けの拡張を作るという事自体にくじけてしまいそうなのだけど。
テストを開始しても、Chrome は起動するもののテストページへのナビゲーションが発生せず、そのままタイムアウトで失敗してしまうことがたまにある。これの原因がよくわからない。とりあえずエラーメッセージとしては “unable to discover open pages” というものが返される。
原因はよくわからない。テスト用とは別の常用の Chrome を起動している状態でテストを開始すると、そういう状況が発生することがあるが、しないこともある。常用の Chrome を落とした状態でも発生することがある。また youtube とかの動画を再生中だと発生する確率が上がるような気がしないでもない。要するに chromedriver が Chrome を起動するものの、複数ある Chrome のうち自分が起動させたものを見失うことがある、というような感じなのだが……そんなわけあるかいな。
上記のエラーメッセージでググっても特にこれだというものもない。謎。
ちなみに Linux 版の Chrome で UI のロケールを任意のものにするには、[cci]LANGUAGE=en google-chrome[/cci] などとする。LANG でも LC_ALL でもなく、LANGUAGE。また、[cci]–lang[/cci] スイッチは効かない。
* * *
というわけで、とりあえずすべての機能テストを java から javascript へ移植した。疲れた。次にこれを Windows 上の Firefox にて通してテストする。とその前に、Linux 上でも動かしてみよう。
ナウい Firefox で Selenium のテストをするには、geckodriver が必要なので、これをパスの通ったところに置いておく。
var options = new firefox.Options();
options.setProfile(profilePath);
result = new webdriver.Builder()
.withCapabilities(webdriver.Capabilities.firefox())
.setFirefoxOptions(options)
.build()
こんな感じで起動。これは既存のプロファイルを利用するような動作を意図しているが、どうも既存のプロファイルを /tmp あたりにまるごとコピーしてから起動するような感じがする。そのため実際に Firefox のウィンドウが表示されるまでは結構待たされる。
それから、webdriver.actions().sendKeys().perform() が未実装なのだそうでエラーになる。その代わり WebElement#sendKeys() を使う。geckodriver 自体が新しいプロジェクトなので、すべての想定された機能が実装されるまでにはもうちょっとかかる雰囲気。
* * *
結局のところ wasavi でテストするには
と入れて、[cci]make run-chrome[/cci] としてとりあえずテスト用プロファイルでもって起動し、開発者モードで wasavi を組み込み、ついでに dropbox などに wasavi からアクセスして認証を得ておき、ブラウザを閉じてから [cci]make test-chrome[/cci] とする……という感じ。ただし Firefox に関しては、過去の記事の通りオンザフライで WebExtensions ベースの拡張を登録するのが現在のところできないので、wasavi をビルドした上で xpi を登録したプロファイルを用意する必要がある。