Linux というか X11 が動いている環境上での vim は [cci]*[/cci] レジスタと [cci]+[/cci] レジスタで PRIMARY セレクションと CLIPBOARD セレクションを使い分けるはずであるが、wasavi ではそうなっていないというもの。
とはいうものの、ブラウザのエクステンションから操作できるのは CLIPBOARD セレクションだけである。とりあえず [cci]*[/cci] だけでなく [cci]+[/cci] レジスタも有効なレジスタと見なし、[cci]*[/cci] のエイリアスとして扱うように修正。
wasavi が何らかのメッセージを出力する場合、いくつかの出口がある:
ここで重要なのは、バックログと message は本質的に同じバッファを共有しなければいけないということと、message と notice の使い分けを正しく行わなければならないということなのだが。前者に関して徹底されていなかった（対症療法的な修正がたくさんコミットログに残ってて結構恥ずかしい）のでそのへんを見直して修正した。
後者は明確なルールがあるわけではない。ただ実際に使ってみた際にログが溜まりまくってうぜえ！的なものは notice、エラーメッセージ的なものは message に回すように見直した。
現在の常用のブラウザはここのところ Firefox beta だったのだが、例の「拡張は署名済みじゃないと入れさせませんぞー！」という仕様変更に対応するため Firefox Developer Edition に鞍替えすることにした。
ということで入れてみた。プロファイルも別扱いになるので、いくつかの設定はやり直す必要があるものの（フォントとか）、それ以外の設定は Sync 経由で復帰することができる。
若干気づいたこと。
最近のだいたい大まかなハイライトはこんな感じ。
ひとつ難しいバグを見つけた。
ex コマンド [cci]wq[/cci] は、write-and-quit の略であり、まさにそのように動作する。これは実質的に [cci]write|quit[/cci] のシノニムであり、全く同じ働きをする。同じ働きというのは、エラー処理も含まれる。つまりこのとき、もし [cci]write[/cci] が何らかのエラーを返したなら、後続の [cci]quit[/cci] コマンドは実行されない。また、保存に失敗したわけなので、もし保存前にダーティフラグが立っていたならば、それは変化しない。ダーティーフラグというのは、最後に保存したテキストの状態から編集が行われているかということを示すものであり、今回のバグの主役はそれだ。
一方で、wasavi での [cci]write[/cci] コマンドの実装は若干特殊である。というのは、write コマンドで直接対象に書き込むわけではなくバッファリングを行うだけで処理を終えるからだ。そういうわけで write の実行結果は必ずしも書き込みが成功したかを示すようにはなってない。が、前述の通り wq は本来 write の実行結果に依存した処理を行わなければならないので、現状だと write エラーの場合に正しく動作していない。現状ではバッファリングが成功した時点でダーティフラグも降ろしているが、本来なら保存処理が完全に成功したことを確認した後じゃないといけない。
ここで、じゃあバッファリングしなければいいじゃんというふうにはならない。特に dropbox などの外部ストレージサービスに書き込む場合にその処理が完了するまではけっこうな間がある。つまりバッファリングが必要な場合としてはいけない場合があるということだ。具体的には ex コマンド列の最後の要素が write コマンドの場合のみバッファリングを許可し、そうではない場合は即書き込み動作に入ってその結果を待つようにしないといけない。
そういうわけで、状況によって細かい場合分けをする必要がある。
| write | wq | xit | ||
|---|---|---|---|---|
| write 動作 | コマンド列の最後 | バッファリングする | 即書き込み、完了を待つ | 編集済みであれば、即書き込み、完了を待つ |
| 最後ではない | 即書き込み、完了を待つ | |||
| quit 動作 | 編集済み | – | write 完了後、write エラーでなければ quit | write 完了後、write エラーでなければ quit |
| 編集済みでない | xit コマンドのコンテキスト内で即 quit | |||
ところであんまり関係ないんだけど、ex コマンド xit って使ったことない。位置づけとしては、タイムスタンプを不必要に更新しない wq ということなのだが。その機能ってむしろ write が標準で持っていてもいいと思うのです。write で更新されてる時だけ書き込み、write! なら常に書き込み動作みたいな。
fFtT コマンド群に対して拡張を行った。似た仕組みを Range Symbols にも取り入れることができる。
たとえば [cci]yi([/cci] はカーソル位置が属する括弧の内容をヤンクする。このときの [cci]([/cci] が、U+0028 そのもの以外に U+FF08 も同一視するようになれば、全角の括弧に対しても Range Symbols の操作を行えるようになる。これは便利かもしれない。同じ拡張を [cci]({[[/cci] の 3 種の括弧について施すことができる。
ただ、これだけではまだ中途半端だ。というのも、特にアジアの東の果ての野郎どもがこれら以外にやたらめったら括弧類を使うからだ。Range Symbols で例えば [cci]【悲報】[/cci] みたいな文字列の括弧の内外を取り扱うにはどのシンボルを割り当てたものだろうか。
また、括弧類以外に、引用符についても拡張の余地がある。あるのだけど考え始めるとなかなかこれもめんどくさい。Range Symbols が認識する引用符は [cci]”‘`[/cci] の 3 種だが Unicode で定義されている引用符はたとえば “ (U+201C) と ” (U+201D) のように開き引用符と閉じ引用符が別である。さらに、困ったことに、Wikipedia によれば、同じコードポイントでも言語によって開き引用符として使われたり閉じ引用符として使われたりするようなのだ。え…なにそれ。
そういうわけで、そういうのにそれなりに対応するにはけっこうというか既存の引用符に関する処理はかなり書き直さないといけないと思う。でもそうなるとこの機能の使用頻度とプログラミングの作業量のバランスがとても良くない気がする…。
今まで wasavi を起動させる要素は、textarea か特定の input 要素か、あるいは contentEditable 属性がオンになってる要素であった。つまるところ、編集できるのはあくまで実質的な木構造の終端の要素であった。
試験的にこれに document.body を含めてみたい。そうするとどうなるのかといえば、つまり何かテキストを編集しているわけではない状態で [cci]Ctrl+Enter[/cci] を押せば wasavi を起動させられるようになる。この時の編集対象要素が document.body ということだ。しかしこれは実質的な終端の要素ではないので、その内容を編集・上書きできるというわけではない（もし上書き可能にすると、とても危険だ。wasavi 上で編集するものはあくまでプレーンテキストなので、その上書きによって失われるかもしれない子要素があまりに多すぎる）。
一方で、save 動作に対する load 動作も特殊だ。document.body の内容全体をプレーンテキストに変換したとしてもあまり意味があるとは思えない。したがって初期内容はページのサマリの体裁が良いと思う。つまり
[title 要素か最初の h1 要素の内容]
[URL]
[meta[name="description"] 要素があれば、その content 属性の内容]
[wasavi 起動直前に範囲選択されていれば、その内容]
という感じだ。イメージとしてはこんな感じにページ全体に覆いかぶさるように起動する。
このサマリ自体は、いかにも twitter とか、あるいはソーシャルブックマークに登録されるそれっぽい感じだ。であれば、まさにその用途に使うようにすればよいのではないか？ つまりユーザが任意のページを開いて、これを SBM に登録したいと考える。その過程でちょっとしたコメントなんかも追記したい（しかも、vi のインターフェースで）。この一連の作業を wasavi が面倒を見ればよいのではないかということだ。
しかし、SBM サービスというのは非常にたくさんあるわけで全てに対応するのは無理だ。また、登録処理自体はテキストエディタの仕事の範疇から外れているし、やるとしたらエディタ内蔵のプラグインやスクリプティング機構が受け持つべきだけど、wasavi はまだどちらも持ち合わせていない。
とりあえず document.body 上でも起動できるようにして、それをどうするかは懸案事項としておこう。
fFtT コマンドについて、従来からある拡張をしていた。カタカナ・ひらがな・漢字のローマ字読みのデータを wasavi 内部で持って、Latin-1 の文字でそれらを指定できるというものだ。つまり「カ」にカーソルをジャンプするには [cci]fk[/cci] すればよい。
今回この対象をカタカナ・ひらがな・漢字以外にも広げたい。特に、Latin-1 ではないラテン文字に対する拡張が中心になる。
元となるデータは、UnicodeData.txt の Decomposition_Mapping である。たとえば U+00C0 (À) のそれは
U+0041 U+0300
という形式に分解される。U+0041 はつまり単に A であり、それに U+0300 が付随している書記素クラスタということだ。このデータの中から最初の Latin-1 内の文字を抜き出して fFtT の代替表現とする。
前述の通りこの拡張はラテン文字が中心なのだが、日本語に関してもいくつか拡張される。
一方、気になる点もいくつか出てきた。
* * *
とりあえず何の変更も加えないことにした。文句が上がってきたらその時考える。
ちなみに、どのコードポイントがどの Latin-1 の文字に代替されるかは github 上の wikiに書いてある。
ひと通り実装が終わった。
ただし以下のものは surround.vim から移植していない。また、surround.vim を読んでそういう機能があると把握してないものがあればそれも当然移植されていない。
とりあえず作業はテスト漬けへ移る。
