いろいろ弄っているのでまた wasavi で取り留めのないことを書いてみよう。

テレビ、具体的には公共放送の相撲中継を見ていて気になるのだが、解説の親方はじめ、あまりテレビ慣れしていないと思われる方々はなぜかインタビューされると「そうですね、」というのを最初に付けすぎだと思う。なんなんだ、イエスマン症候群か。

それ系のことに注意してテレビのインタビューを見ていると、能動態と受動態の混乱とか、「～だし、～だし、～だし、……」という「『し』の行進」とか、「○○は、××が△△という○○」みたいな口語ならぎりぎり許されるレベルのへんてこな文構造とか、「～なんですけどー」（けど、何？）という定型的な語尾とか、いろいろ気になり始めるのである。

しかしまあ、気にしたら負けなのだろう。たぶん。

　＊　＊　＊

ちなみにここまで wasavi on opera で書いてみて、なんか笑っちゃうほど buggy なので結構がっかりしているところである。ああ……。

一応 Opera の名誉のために書いておくと buggy なのは Chrome/Opera/Firefox で同じような動作をさせようとしている wasavi のコードであって、Opera は悪いか悪くないかといえばとりあえず悪くはない。しかし根本的な原因をさかのぼれば、いろいろと回りくどい動作を強いる Opera が悪いのは言うまでもない。

ぼちぼち、Google 日本語入力でも安定して入力できるようになってきた。とはいえまだびみょーにあれ？　という点がある。それを洗い出すためにとりとめのないことでも書いてみよう。

今使っているキーボードは Thinkpad USB Keyboard with trackpoint というやつなのだが、最近になってというか昨日のことなのだが「=」キーの効きが悪くなった。押下して、感覚的に入力されるかな？　というタイミングで入力されない。そこでキートップを外してみた。

キートップを外すのは割と簡単だ。パンタグラフの四隅が、キートップの裏のそれぞれのかみ合わせに引っかかるようになっている。そこでマイナスドライバーをまずキーの下側の真ん中に差し込み、くるっと回す。同様に上側からもドライバーを差し込み回す。回すのはゆっくりではなく素早くやったほうが良いようだ。

ちなみに tab キーを始めとする横に長めのキーは四隅というにはちょっと中心部分に寄ったところがかみ合わせになっているので、ドライバーでくるっ、も 4 回に分けたほうが無難だ。

というわけで外してみたところ、細い毛がラバーカップの上に乗っていた。こんな微妙な原因でキータッチの感覚が変わってしまうのかー。

などと書いていて早速気づいたが、変換した時に出てくる候補のポップアップが仮入力文字列の上にかぶさっていてとても見にくい。うーんテストページではちゃんと表示されるんだけどな。カーソルの要素が position:fixed なのが問題なのかしらん？　とりあえずいろいろ調べて見ることにしよう。

　＊　＊　＊

どうも Opera のバグのようだ。wasavi の iframe に box-shadow をかけて、さらにその iframe が position:fixed か position:absolute だったとき、おそらく内部的には原点が影の分だけ左上に移動するのだろうが、変換候補ポップアップについてはそれを考慮した補正を忘れている。とそんな感じだと思う。Chrome や Firefox ではそういった現象は起こらない。また、これが起こるのは Windows だけのようだ。

ということでバグレポした。DSK-380712。

Opera が悪い。

勘違いだった。Google 日本語入力でも、イベントの発生の仕方は同じだった。wasavi 側の対応をちょっと修正。input モード時はカーソルを消去しないようにした。

ちなみに、キーボードの入力のテストは http://appsweets.net/wasavi/keytest/index.html で行うことができる。手元には Windows+ATOK とか、Mac OS X の環境がないので確認できない。それらの環境で、compositionstart、compositionupdate、compositionend イベントが Chrome や Firefox と異なる振る舞いをしていたら教えてください。

Ubuntu でも試してみた。iBus+Anthy、iBus+mozc の両方で、仮入力中はなぜか keydown イベントが発生しない。input や keyup イベントは発生する。うーんどういうことなのか。keydown イベントが発生しないとそもそも composition events のエミュレーションを開始すること自体ができないのだけど。これはどうすることもできないかもしれない。

いやー本当に、Opera は、ダメなブラウザだ。Opera が悪い。

wasavi の設定は、基本的には exrc、つまりエクステンションが保持する localstorage の項目に書いておく。しかしこれだけだといろいろと煩雑だ。また、wasavi を使用するのは何かを送信するフォーム内の textarea というケースが最も多いと思うが、ajax を駆使したフォームでもない限り送信することでページが更新されるので、送信前の wasavi でテンポラリ的に :set なんちゃらした値は送信と共に失われてしまう。

これをなんとかしたい。つまり、wasavi の実行中に動的に変更したオプションを、ページの更新を超えて自動的に再現したい。

ここで難しいのは、ページ更新前に与えた wasavi の設定が、更新後の html 内のどの textarea に対応するか、という判定だと思う。たとえば textarea に id が振られていれば、それを判断の材料にできる。しかし id に頼るのは危険かもしれない。論理的には更新前後で同じ textarea だったとしても、サーバ側の都合で異なる id を振られている場合が考えられるからだ。

id ではなく、たとえば html のルート要素から textarea へ至るパスを頼るのはどうか。つまり html->body->div->textarea みたいな感じの文字列をキーにしたハッシュを保持して、それに設定を書いておく。実際は、html(1)->body(1)->div(3)->textarea(1) みたいに要素のインデックスも必要かも。

この構造が更新ごとにダイナミック、あるいは微妙に変化する html ページってあるかなあ。たとえば更新ごとに div 内の最初に textarea が配置されたり最後に配置されたりするページ。ないとは言えないか。そうすると、ノード名を単語とみなした sentence similarity measure を測ったりする必要があるかもしれない。めんどうだなー。

　＊　＊　＊

よく考えたらこの話題は別に Opera に文句をつけるものではなかった。まあいいか！　Opera が悪いのは事実だし！

Opera で擬似的に composition events を実装する場合、様々な処理を最終的に keyup ハンドラ内で行うことになる。これはひとつ奇妙な振る舞いを引き起こす。キー入力は、基本的には keydown -> keypress -> input -> keyup の流れでイベントを発生させるのだが、しかし高速にキーボードを捌いたりすると、複数のキー入力の各サイクルがオーバーラップしてしまうことがある。

といっても Opera に問題があるわけではなく、つまりキーボードの打ち方の問題で、例えばあるキーを離す前に次のキーを押したりした場合だ。そうすると keydown -> keydown -> keyup -> keyup みたいな感じでイベントが発生する。

これを考慮しないと、正しく composition を認識できない。ので、考慮するようにした。

　＊　＊　＊

keydown および input イベントの引数 e を蓄えておくキュー、keyup イベントの引数 e を蓄えておくキューを保持する。前者のキューの 1 項目は、

{
keyDownEvent: { ... },
currentString: '',
inputEvent: [ ... ]
}

てな具合。keydown イベントハンドラで、keyCode が 229 だったら IME に対する入力とみなし、ハンドラ本体の本来の処理はせず、キューに必要な情報を埋めるだけにする。keyup イベントハンドラで、keydown キューの長さ – 1 == keyup キューの長さではない場合、つまり keydown イベントが複数回連続して発生した状況である場合は、keyup キューに必要な情報を埋めるだけにする。

keydown キューと keyup キューのバランスが正しい場合は keyup ハンドラ本来の処理を行うが、それに先駆けて溜まったキューを処理する。イベントの引数 e をもって keydown、input イベントハンドラを直接呼ぶ。

　＊　＊　＊

composition 文字列が更新されるごとに直前の文字列の長さを覚えておくようにし、暗黙的確定のようであれば直前の compositon 文字列のほうを採るようにした。つまり暗黙的確定にも対応した。

しかしだからといって Opera でも IME に対応しました！　とはとても言えない。だいたい IME に対する入力時の keyCode、229 って何なのかさっぱりわからない（IE に準じているっぽいが）し、明示的確定では input イベントが連続して 2 回、暗黙的確定では 3 回とかどこにも文書化されてもおらずそもそもバグの産物なのかも知れず未来のバージョンでもそれが維持されるかもおぼつかない。ダメダメすぎる。Opera が悪い。