漢字以外の文字を考える。漢字以外とはつまり、ひらがな・カタカナ、および一部の全角文字……にしようと思っていたが、せっかく漢字の読みについては Unicode のデータを参照するようにしたのだから、こちらもそうしよう。

ひらがな・カタカナについては、UnicodeData.txt を参照する。これらの読みのデータは入っていないが、文字名が “HIRAGANA LETTER KA” とかなのでそこを取り出す。ちょっと強引。

残りの文字も UnicodeData.txt から取り出すのだが、bmp 全体を対象にし、データベースの 5 番目のフィールド、Decomposition_Type と Decomposition_Mapping を参照する。Decomposition_Mapping の先頭の文字が Latin-1 の U+0020 から U+007F であれば、fFtT の対象にする。ちなみに先頭の文字をただ取り出すのではなく、Decomposition できなくなるまで再帰的に変換する必要がある。

生成するデータの構造は、bmp のコードポイント 2 バイトと、変換先文字のコードポイント 0x20 から 0x7f の 1 バイトで計 3 バイト。

というわけで生成させてみたところ、1574 文字分、4722Bytes のデータができた。あら小さいのね！

これによって生成したデータにより、例えば㍇とか①とかʣといった特殊な文字でも、それぞれ Latin-1 の文字 m、1、d を対応させることが可能になる。これはつまり、例えば一般的な日本語の文章でも、下記のように Latin-1 の文字を使って各文字に自由に fFtT できるようになるということだ。

a a m ! f w m m ! !
ああ㍇！　ふわ㍉　㍇！！


j a
k d g
m o h k k
j s s i m n m
y t m m d t w m t n i z k t h m o r w s i t
柚純㎟まだ終わ㍇てないぞ　今度は㎟後ろを向いて


たださらに微調整の余地はある。助詞としての「は」は w で飛べたほうが自然かも。濁点や半濁点付きの半角カナに対応していない。悪名高い円記号とバックスラッシュの問題。また、上の例の「後」のように、「うしろ」と読めるはずなのに u が定義されていない、Unicode の仕様自体の不備も気になる。もっとも、Unihan_Readings.txt 内の kJapaneseOn と kJapaneseKun は status:Provisional だそうなので文句を言うわけにもいかないのだが。

ちなみに変換表は

• 一般
• 漢字の日本語での読み

となっている。漢字のほうはそれなりにでかいので注意。

fFtT を日本語対応にするために辞書を作る。まず漢字。必要なデータは、コードポイントとそのコードポイントのローマ字読みの先頭のアルファベット。

もしかすると、コードポイントは不要かもしれない。Unihan_Readings.txt がサポートする U+3400 から U+FA2D（とりあえず BMP 以降は考えないことにする）の配列という形にすればインデックスでアクセスするだけでいい。50733 文字もあるけど……。しかし調べてみると、その中で音読み・訓読みが定義されているのは 13369 文字だけだった。となるとやはりコードポイントは必要か。

一方、読み先頭字はというと、アルファベット 26 文字分のビットフィールドということになる。つまり 4 バイトを消費するのだが、こちらもまた調べてみると実際に使われる文字はもう少し少ない。ローマ字なので例えば L とか Q とかはまあないのだ。具体的には

7647 K
6664 S
4033 T
3514 H
2188 M
1594 G
1545 Y
1538 N
1494 R
1328 A
1319 O
1294 B
1057 I
943 J
855 C
808 U
772 D
625 E
499 F
407 W
6 P

こんな感じで 21 字で済む。そうすると 3 バイト。うーんなんとか 2 バイトに詰められないかな……。まあ、とりあえず 3 バイトにするかな。そうすると 1 エントリあたり 5 バイトの、13369 字分ということで 65KBytes になる。けっこう小さくなるなー。

参照する際は、コードポイント順に並べてある前提で 2 分探索することになる。

vi コマンドに f、F、t、T がある。これらのキーを押すとさらに 1 文字入力を求められ、カーソル位置から最も近いその文字のところへカーソルがジャンプする。非常に良くできた機能。

なのだが、日本語との相性は非常に悪い。vim では 1 文字入力待ちの状態で IME をオンにして……ということ自体はできるのだが、それでもまだるっこしい。

これ、ひらがな・カタカナ・漢字についてローマ字の読み、Latin-1 に基本形を持つ全角文字のその基本形、などを内部的に持っておいて、それを利用できないか。つまり「日本語の文章」の先頭にカーソルがあるとき、[cci]fb[/cci] と押せば「文」のところにカーソルが飛んでくというイメージ。若干 migemo と考え方は似ている。

問題は、どうやってローマ字の読みを得るかだ。ネイティブアプリなら、IME が提供する再変換 API で読みを得られるだろう。または MeCab のようなものを呼び出してもいい。しかし wasavi では無理だ。そういう web サービスはいくつかないこともないが:

• 日本語形態素解析API
  http://developer.yahoo.co.jp/webapi/jlp/ma/v1/parse.html
• Google CGI API for Japanese Input
  http://www.google.co.jp/ime/cgiapi.html

しかしコマンドを実行するごとにネットワークアクセスが発生するのはなかなかに富豪的すぎる。何とかローカルのデータでもてないか。しかもできるだけコンパクトに。

Unicode の仕様の中に、unihan というものがある。これは CJK Ideograph、いわゆる漢字についてのさまざまな情報を集めたものだ。その中に、Unicode に収められている漢字について訓読みと音読みを定義しているデータベース Unihan_Readings.txt がある。例えばこんな感じ:

㞮 kJapaneseKun DERU DASU
㞮 kJapaneseOn SHUTSU SUI
㡡 kJapaneseKun TOBARI KAYA
㡡 kJapaneseOn CHU JIU
一 kJapaneseKun HITOTSU HITOTABI HAJIME
一 kJapaneseOn ICHI ITSU

これを元にぎゅっとつめ、せいぜい数十～数百 KB 程度のデータにならないかな。

vi のコマンドには、x/X、p/P、のようにペアになっているものが少なくない。内部的にも同じような処理でほんの一部のパラメータだけが違う、といった感じになっている。ちょっと無駄なので、できるだけまとめるようにした。

　＊　＊　＊

めっきり寒くなってきたので、コタツと Thinkpad X121e が再びフル回転することになる。Thinkpad に Thinkpad USB keyboard with trackpoint を付け、キーボードはコタツの中に入れるのである。

まったく死角がない！

　＊　＊　＊

ところで X121e、購入から 1 年経過して保障が切れたあたりから、AC 電源に接続しているのに勝手に放電状態になったりすぐ戻ったりなんだか怪しい。なんなんだ、レノボタイマーか。

　＊　＊　＊

普段 vim を使うときは gvim なのだが、cygwin の vim もけっこう使う。で、cygwin を全画面表示 + 背景透過などにするとなんだかなつかしの PC-98 的 DOS 環境な感じで嫌いじゃないです。うぉー今コードを書いてる！　書いてるぜー！　って感じになる。まあ 98 持ってなかったけど。

うぉー今コードを書いてる！　書いてるぜー！

input モードのショートカット ^T、^D をなんとかしよう。

これらの機能、実はあまり利用したことがない。とりあえず ^D の posix の仕様は以下の通り:

^D
^D は、行指向コマンド（/, ?, :, !）によって開始されたテキスト入力モードでは特別な意味を持たない。またこのコマンドは、ブロックモードの端末ではサポートされてなくてもよい。

カーソルが字下げ文字に続いていない、または字下げ文字、’0′ または ‘^’ に続いていない場合:

1. カーソルが 1 桁目にある場合、^D は無視され何も起こらない
2. そうではない場合、^D は何の意味も持たない<（^D そのものが挿入される）

最後に入力した文字が ‘0’ であった場合、カーソルは 1 桁目に移動しなければならない。
そうではなく最後に入力した文字が ‘^’ であった場合、カーソルは 1 桁目に移動し、加えて、次の入力行の自動字下げレベルは現在行の（もともとの）字下げ量をもたらした行から同様にもたらされなければならない。

そうではない場合、カーソルは shiftwidth 単位で前に戻される。

現在行: 変更されない。
現在桁: ^D の前に ‘^’ または ‘0’ があった場合は 1。そうでない場合は (column -1) -((column -2) % shiftwidth)。

という感じ。結局のところはインデントを制御するショートカットということだ。なお vi では ^D はカーソル行が /^\s+[^0]?/ な状態のときのみ効力を持つのだが、vim では拡張されいつでも実行可能になっている。

この中で、異質なのはもちろん ‘0’ や ‘^’ を前置した上で ^D すると特別扱いされるという点だ。これらの文字を打った直後に ^D を押すと、カレント行のインデントが削除される。0 と ^ の違いは、インデントの削除が一時的かどうかだ。[cci]:set ai[/cci] な状態で、前者はインデントを削除した行で enter を押した場合、次の行もインデントなしになる。つまり、カレント行が次の行のインデント量を算出する基準になる。一方後者の場合、カレント行は次の行のインデント量を算出する基準から外される。これは例えば、C ソースでラベルを書く場合とかに有用:


foo();
loop:
bar();


なんてコードだと、1 行目で改行した時点で自動的に 1 レベルのインデントが挿入されるが、そこで ^^D し、1 桁目から loop: と打つ。で、さらに改行すると、新しい行のインデントは 2 行目ではなく 1 行目から派生し、1 レベルインデントが生成される。ちなみにインデント量が補正された場合、’0′ や ‘^’ は自動的に削除される。

というわけで、そうなるように実装した。

さて、vi の input モードで定義されている特別な機能はこれで一通り実装したのだけど、実はもうひとつだけ残っている。input モードに入った直後に NUL、つまりコードポイント 0 の文字を入力すると、最後に input モードに入力した文字が自動的に再度入力され、かつ input モードも自動的に抜ける。

この機能はどうなんだ。まずキーボードから NUL って入力できていいのか？　一般的にコントロールコードは Ctrl + A とかで打つ。そうすると、A のコードポイントを 0x1f で論理積を取った値をコードポイントとした文字が打たれたことになる。そう考えるとコードポイント 0 は Ctrl + @ になる。しかし US 配列のキーボードの場合 @ は Shift + 2 で打つので、実際には Shift + Ctrl + 2 ということになるが、これだと制御キーのためのショートカットだとキーイベントハンドラで判別できない。javascript ではキーボードレイアウトを意識するのは非常に難しいのだ。

とりあえず、ctrl+space を特別扱いし、それが押されたら wasavi の中では NUL が押されたことにする。

というわけで、その機能も作った。

いろいろ逡巡したが、vim と「だいたい」同じ動作をするようにする。たとえば入力開始位置は ^W の動作に影響を与える。

それから、入力開始位置を保持するのにテンポラリ的なマークを設定しているのだが（wasavi のマークは vim と違い、桁方向についてもテキストの編集による増減に追従するので流用できる）、それにより副作用的に gi コマンド、つまり最後の入力終了位置へジャンプする機能も実現可能になるので、付けた。これは割りと便利ですよね。

入力開始位置は、基本的には input モードの 1 セッション中は変化することはないが、backspace や ^W でどんどん前方へ削除していった場合、カーソル位置が入力開始位置より前に来てしまう。この overrun な状況は、以下の動作に影響を与える。

1. R コマンドで overwrite モードに入っている場合。入力開始位置より前方にカーソルがある場合、
   • 元のテキストの上で backspace や ^W を押しても、カーソルは移動するものの削除は行われない
   • 元のテキストを上書きしたテキストの上で backspace や ^W を押した場合は、元のテキストが復活する

   wasavi では元のテキストの復活処理はまだ組み込んでいない。

2. ^U の処理。^U は入力開始位置からカーソル位置までを削除する。入力開始位置より前方にカーソルがある場合、次の候補
   • カーソル行の行頭
   • [cci]:set ai[/cci] してある場合は、カーソル行の最初の非空白文字のある位置

   が選択され、いずれかのうち、カーソルより前方にありかつカーソルに最も近い位置が最終的に残る。この位置からカーソル位置までが削除される。

3. 文字を入力した場合。入力開始位置はそこに更新される

overwrite モードでの overrun はそもそもそれが起こらないようにクリップするだけにとどめるかもしれない。ちゃんと作ろうとするとかなり大変だ（しかも大変な割にめったに使わない）。

　＊　＊　＊

overwrite モードでの overrun 状態。入力開始位置より前方へのカーソルの移動は可能だが、編集しようとするとエラーになるようにした。

input モードの動作と「.」レジスタ、「.」コマンド、および undo ログとの整合性をとる作業。だいぶ良くなってきた。

次に、^W あたりを片付けよう。これは input モード中、カーソル位置の直前の単語を削除する。

• input モードに入った入力開始行・桁位置までは、undo ログではなくて現在の入力文字列を操作する（undo ログは backspace/delete/escape などのキーが押されたときに生成されるので）。入力開始位置をさらにさかのぼる場合は、undo ログを生成する。単語の両端が入力開始位置の前、後に亘っている場合はどうするか？
• ちなみに、^W が入力開始位置をさかのぼれるのは（[cci]:set bs=2[/cci] した場合の）vim の機能であって vi や nvi では入力開始位置より前には戻れない。wasavi は戻れるようにする。つまり vim 互換にする
• ^W の動きはコマンドモードで db した場合に似てるのだが、微妙に違う。たとえば ^W は 各行の 1 桁目で必ず止まるとか。これはなんで？

この辺に留意しつつ vim のソースを眺めてみる。

　＊　＊　＊

たとえば [cci]ifoo^[[/cci] と打ち、続けて [cci]abar[/cci] 左矢印 [cci]^W^[[/cci] と打ったとき。つまり

foobar
^ ^カーソル位置
|
+挿入開始位置
という関係。ただし、^W を打つ前に左矢印キーを打っているのでそこで挿入開始位置は更新され（input モード中の矢印キーは、いうなれば [cci]^[i[/cci] と打つようなものである。挿入開始位置はその時点のカーソル位置に更新される）、

foobar
^カーソル位置、挿入開始位置
という関係になる。

• 入力文字列: “^W”
• 入力コマンド: “a^W^[“
• undo ログ:
  1. 桁 0 へ ‘foo’ を挿入
  2. 桁 2 へ ‘bar’ を挿入
  3. 桁 0 から ‘fooba’ を削除

となる。つまりこのケースでは挿入開始位置と削除される単語の位置関係は、単語が完全に挿入開始位置の前方に位置しているということになる。すなわち、undo ログを生成する必要がある。

一方、[cci]ifoo^[[/cci] と打ち、続けて [cci]abar^W^[[/cci] と打った場合は、挿入開始位置との関係が変わる。

• 入力文字列: “bar^W”
• 入力コマンド: “abar^W^[“
• undo ログ:
  1. 桁 0 へ ‘foo’ を挿入

vim では input モード中の単語削除を行うために、削除される領域の左端を走査するループを行うのだが、このループは挿入開始位置で必ず抜けるようだ。つまり、削除領域が挿入開始位置をまたぐことはない。単に領域全体が挿入開始位置より前方か後方かの 2 パターンで考えればいい。このケースでは削除領域は挿入開始位置より後方であり、現在の挿入文字列を操作だけで undo ログは生成しない。

この仕様が妥当なのかどうかは、よくわからない。この仕様だと途中で打った “bar” は undo ログから完全に失われる。もっとだだ長い単語だったら再利用したい場合もあるのではないだろうか？　あるいは、[cci]:set bs=2[/cci] な vim で input モード中に挿入開始位置より前にも自由にカーソルを再配置できるというのは、つまりユーザに挿入開始位置を意識させないためのものであるはずだが、しかし単語削除時については挿入開始位置を意識させることを強いるのは変な話なのではないか？

^W が押されたときに必要ならそこまでに生成された挿入文字列から undo ログを生成し、挿入開始位置をカーソル位置に更新すれば、削除処理は常に undo ログを生成する backspace でまかなうこともできる。どちらがいいだろうか悩むところだ。ただし、この単純化した処理は ^U には適用できないので（^U は「挿入開始位置からカーソル位置までの入力文字列を取り消す」。暗黙的に挿入開始位置を参照するわけではない）、vim 互換の処理が完全に不要というわけではない。

vim では、このへんは edit.c でやっている。input モード中の backspace 処理は ins_bs() が担当している。この機能はコマンドモードで db した場合と確かに似ているのだが、処理は ins_bs() で完結している。

まず backspace、つまりコントロールコード \u0008 を考える。キーボードから “ifoa^Ho^[” と打つと:

• 入力テキストは “foa^Ho”
• 入力コマンドは “ifoa^Ho^[“
• undo ログは 3 つのアイテムを含んだクラスタ: “桁 0 へ ‘foa’ の挿入”, “桁 3 から後方に 1 文字削除”, “桁 2 へ ‘o’ の挿入”

また、キーボードから “i^H^H^[” と打った場合は:

• 入力テキストは “^H^H”
• 入力コマンドは “i^H^H^[“
• undo ログは “桁 0 から後方に 2 文字削除”

となる。なお vim の場合、^H と backspace を内部的に区別しているのだが wasavi ではそこまではしない。どちらも \u0008 として扱う。

追記: カーソルが 1 行 1 桁、つまりバッファの先頭にあった場合に上記ストロークを打った場合は、

• 入力テキストは “”
• 入力コマンドは “i^[“
• undo ログは生成されない

となる。この状態で . コマンドを実行するとカーソルが左に 1 文字移動するように見えるのは、つまり “i^[” の副作用だ。

次に delete。これに対応するコントロールコードは、wasavi においては ^_、つまり 0x7f だ。”d” の上にカーソルがある状態でキーボードから “i^_b^[” と打てば:

• 入力テキストは “^_b”
• 入力コマンドは “i^_b^[“
• undo ログは 2 つのアイテムを含んだクラスタ: “桁 0 から前方に 1 文字削除”, “桁 0 へ ‘b’ の挿入”

となる。考え方は backspace と同じ。

一方、特殊キーはどうか。input モードにおける特殊キーというのはつまり、カーソルを移動させるキー: 矢印キー、Home、End、PageUp、PageDn のことだ。そして input モード中のカーソル移動というのは、実はいったん command モードへ抜け、vi コマンドによりカーソルを移動させ、再度 input モードに入るという手順と意味は同じなのだ。したがって最初の input モードで入力した文字列と次の input モードで入力した文字列はそれぞれ独立したものとなる。これは undo ログも同じ。”ifoo” 左矢印 “bar^[” と入力した場合、左矢印キーを押した時点でまず

• 入力テキスト: “foo”
• 入力コマンド: “ifoo”
• undo ログ: “桁 0 から ‘foo’ を挿入”

という結果が生成されるが、直後に新しい input モードのセッションが開始する。undo ログはリスト構造であり、独立した 2 つのログが最終的に生成されるが、入力テキストと入力コマンドはそうではないため上書きされ、最後のセッションの結果が残る。つまり最終的に

• 入力テキスト: “bar”
• 入力コマンド: “ibar^[“
• undo ログ: 2 つのクラスタ
  1. “桁 0 へ ‘foo’ を挿入”
  2. “桁 2 へ ‘bar’ を挿入”

となる。undo ログが独立しているというのは、u を押すとまず bar が削除され、さらに u を押すと foo が削除されるということだ。なお、undo ログで桁位置も記録しているが、挿入系と削除系で意味合いが違う。前者は入力を開始した位置、後者は現在のカーソル位置だ。入力開始位置は input モードのセッション中は不変だが、backspace / delete で新規セッションが強制開始した場合は入力テキスト・コマンドと共に初期化する必要がある。

引き続き、input モードに不足している部分を補っていく。

ちなみに input モードというのは、i とか a とか押すと遷移する例のモードのことだ。vi が起動してすぐの状態は “command モード” だと一般的に浸透している（と思われる）のに対し、例のモードは “insert モード” とか “edit モード” とか、微妙に表記が定まっていない気がする。しかし posix の定義に倣うならば、例のモードは “input モード” で、とりあえずそう書くことにする。正確には input モードは総称で、実際には insert モードと overwrite モードがある。

input モードで何がめんどくさいかというと、backspace/delete の振る舞いおよび、一部の特殊なキー入力（矢印キーなど）がサポートされている点だ。

input モードでは、以下の情報が逐一更新される。

• 入力開始位置
• 入力したテキスト。これは input モードを抜けた後にレジスタ “.” に格納される
• 入力したコマンド。これは input モードを抜けた後に “.” コマンドで再生されるべきもの
• undo ログ

これらの更新と、backspace/delete および特殊なキー入力による機能が矛盾なく両立させないといけない。また、abbreviation も考慮する必要がある。”f” を “foo” に展開するような abbrev があったとき、キーボードから “if bar” およびエスケープキーを入力すると:

• 入力したテキストは [cci]f^Hfoo bar[/cci] となる（vim では）
• 入力したコマンドは [cci]if bar^[[/cci] となる

ちなみに map の展開はこの前の段で完了しているので、入力されたテキスト、コマンド共に格納されるのは map 展開後の何かだ。ところで abbrev の展開が ^H 付きの構造になってるのってどういう意味あるのかな。別に単に展開後の文字列に置き換えても構わない気がする……。

Chrome 版と Opera 版 wasavi のエクステンションパッケージは、javascript ソースを minify して格納している。

そもそもローカルファイルシステムに展開されるソースを minify して効果あるのか？　と考えると、ほとんどないわけだけど、前にも書いた気がするが、closure compiler のような変態的な変換を行う可能性もあるので、とりあえずそういうプロセスを経由してビルドするようにしている。ただし Forefox 版は、minify するとレビュアの人に怒られるので、そのまま。

で。

minifier はいろいろあるのだが、いまのところ Microsoft 製の Ajax Minifier を使っている。一方最近、wasavi のソースは strict mode に移行した。さて AjaxMinifier は strict mode に適合する出力を行うのか？　というとどうもそうではないようだ。文字列リテラル中に \uxxxx のようなものがあると、AjaxMinifier はそれを可能なら（というより短くなるなら）\x + 8 進表記に直す。しかし strict mode では 8 進表記は禁止なのだった。したがって、そのソースを含んだ wasavi をインストールしても起動しない。

どうするか。まず AjaxMinifier に渡すオプションに -strict:true を明示すると……変化なし。そうではなく、-minify:false を含めるといいようだ。これを含めても、コメントと改行の削除は行われる。なんだか限りなくバグに近い仕様のような気もする。-strict を指定したなら出力も strict mode に適合させるようにしてほしいところ。

それはそれとして、とりあえず生成したパッケージがそれぞれのブラウザで動くところまでは確認した。この辺も自動化できるといいんだけどなー。