[cci]/[/cci] および [cci]?[/cci] コマンドには、デリミタに続けてオフセットを付加することができる。オフセットには符号を先行させてもよい。つまり
/foo/+
/foo/1
/foo/+1
はいずれも、カーソル行以降の foo を検索し、その次の行にカーソルを移動させる。同様に
?foo?-
?foo?-1
はカーソル行より前の foo を検索し、その前の行にカーソルを移動させる。

オフセットを付加したとき、モーションは行志向であるとみなされる。ところでこのオフセット機能は POSIX で定義されているものなのだが、オフセットを付加した時の桁位置はどうなるのかというとなぜか記述されていない。大抵の場合、行志向のモーションはカーソルをその行の最初の非空白文字に置くので、そうした。vim もそうなっている。

ちなみに POSIX ではデリミタ以降にオフセットではない余計なものがついてたらエラーにしなさいとか、オフセットを計算した後の行位置がバッファの先頭行や最終行を超えていたらエラーにしなさいとか、オフセットの他に z コマンドも有効としなさいとか言っているのだが、その辺は実装していない。vim も実装していない（たぶん）。

ノーマルモードでの [cci]^A[/cci]、[cci]^X[/cci] を作った。このコマンドは [cci].[/cci] の対象にもなる。

次に、bound モードでの動作を考える。vim では visual/visual line/visual block モードでも増減ができる。ノーマルモードではカーソルが位置する数値文字列が対象になるが、visual 系（謎）モードでは、選択された領域の各行の、最も左端にある数値文字列が対象になる。これは若干違和感がなくもない。選択された領域内のすべての数値文字列が対象になってもおかしくないのではないのか？　後で考える。

ちなみに、それを作るときにも書いたが、vim における visual 系モードは wasavi では bound/bound_line モードになっている。なぜモード名を変えたのかといえば、そもそも vi というものが ex の visual モードにほかならないからだ。命名がダブっている。

　＊　＊　＊

bound モードでも動作するようにした。vim と違い、領域内の全ての数値文字列が増減の対象となるようにした。

それから、vim のように [cci]set nrformat+=octal[/cci] などという特殊な代入をできるようにするかどうかだが、とりあえず、保留。

最近日本語の文章をちょっと多めに書く機会がある。そのために端末上の vim を使っているわけなのだが。

いまさら書くまでもないのだが、vi と IME を経由した入力の相性はとっても悪い。特に、ノーマルモードにいる状態で IME がオンになっている場合にぐぬぬとなる。せめてこれだけでもなんとかならないのだろうか。

IME が fcitx 上で動いている場合、[cci]/usr/bin/fcitx-remote[/cci] コマンドによって IME の状態を操作することができる。なので、vim のそれっぽいイベントに自動コマンドを引っ掛けて fcitx-remote を適当に呼んでやる。

autocmd InsertLeave * silent! !fcitx-remote -c

こうすると insert モードを抜けた時、必ず IME がオフになる。これでいくらかましになるかなー。

ちなみに wasavi の場合、ノーマルモードに戻るとやはり自動的に IME が無効になるようにしてある。実はノーマルモードでキーボード入力を受けるのは、隠された input[type=”password”] 要素なのだ。大抵のブラウザが、この要素がアクティブなときは IME を無効にすることを利用している。

残念ながら、IME の状態を直接的に制御するような API は javascript にはまだない。

issue #145。

これは、vimの [cci]^A[/cci] および [cci]^X[/cci] が欲しいよという要望だ。これらは、カーソルの下にある数値らしきものを指定したカウンタの分だけ増減させる。[cci]^A[/cci] は増加させ、[cci]^X[/cci] は減少させる。

オプション [cci]nrformats[/cci] の値によって動作をカスタマイズできる。これはカンマ区切りで文字列を格納する前提になっていて、以下のコンポーネントが意味を持つ:

• alpha – \b[a-zA-Z]\b をアルファベットのリストアイテムと認識する。大文字か小文字かで分類し、それぞれ [a-z] と [A-Z] をローテーションする
• bin – 0b[01]+ を2進数表記と認識する
• hex – 0[xX][0-9a-fA-F]+ を16進数表記と認識する。大文字か小文字かどちらかを取るかは、マッチした文字列の最も右端に位置するアルファベットに依存する。アルファベットがない場合は、2文字目が x か X かに依存する。
• octal – 0[0-9]* にマッチし、かつ、0[0-7]* にもマッチする部分を8進数表記と認識する。なぜこれだけ判定がややこしいのかというと、00018 のような文字列を 0001 と 8 に分割されてしまうのを避けるため。またこのコンポーネントを有効にすると、どうでもいいことだが C 言語と同様 0 は8進数の0と認識される

これらのコンポーネントに対するマッチの最後に、必ず -?[0-9]+ を10進数表記と認識する処理が入る。で、カーソル行に対してマッチした文字列群のうち、カーソルの桁位置を内包するものが処理対象になり、指定したカウンタの分だけ値を増減する。基本的には以上だ。

いくつか気を付けるべきポイントがある。

• 0 で始まる、10進数以外の数値文字列の場合、値を増減してもできるだけ元の桁数を維持するよう適宜左に 0 をパディングする
• 10進数と認識される数値文字列（これには、0で始まるが [89] を含む数値文字列も含む）の場合は、逆にいかなる場合も先行する 0 をすべて削除する
• vim の仕様だと、-0001 みたいなのは octal を含んだ nrformats の場合に若干不自然な動作になる。つまり負の符号が先行しているが、正の8進数文字列と認識される。これはいいのか？
• Selenium のテストで、あるテスト中に複数のアサーションを行う時、”#1-1″ とか “#1-2” とかラベルをつけている（そもそも複数のアサーションを詰め込むべきでないとか、もっと自己記述的なラベルにすべきとかはこの際置いといて）このラベルの右端の数値を増減させたい場合、ハイフンが邪魔になり動作が反転してしまう。これはなんとかならないのか。つまり負の符号ではなくハイフン、あるいは減算の演算子であるかを判別できるといいんだけど
• vim では、nrformats の型は文字列だが、実質的にはカンマ区切りの配列構造として扱うことになる。これは身近な例で言えば DOM における className と classList の関係に似ている。全体をまるごと書き換えるのでなければ、classList を通して操作するほうが圧倒的に便利だ。同じことが vim にも言えて、[cci]set nrformats+=foo[/cci] とか、[cci]set nrformats-=bar[/cci] のような演算子が用意されている（vim の、というか vi の set 構文はいわゆる普通のプログラミング言語とは若干趣が異なるので演算子と言っていいのかはわからないが）。これを wasavi でもサポートすべきか？

たとえば

foo
bar
foo
bar
foo
bar
foo
bar
foo
bar

という 10 行のテキストがあり、カーソルは最終行にあったとき、テキスト全体をコピーして末尾にペーストしたいとする。

vi コマンドであれば、[cci]ggyGGp[/cci] で 6 手である。ex コマンドにおいても [cci]:1,t.[/cci] と 6 手。個人的には行単位のコピーは ex コマンドを使うほうが多い。

ところで [cci]:%t.[/cci] のほうがさらに 1 手少ないが、別に vi/ex ゴルフがこの記事の主題ではない。上記の ex コマンド中、[cci]t[/cci] はコピー命令であり、その直前までが行の範囲を示している。開始行は 1 で、カンマが続き、そして終了行は省略している。省略するとカーソル行が割り当てられる。その処理を wasavi に入れ忘れていたので、入れた。

[cci]s[/cci]コマンド中にバックスラッシュによるエスケープシーケンスを含んだコンポーネントを含めると正しく引数が解析されないのを修正。

つまり、[cci]:%s/$/ \\/g[/cci] みたいなのが正しく動作しなかった。

そろそろ各ブラウザの公式エクステンションストアに置いてるwasaviをアップデートする頃合いだ。

　＊　＊　＊

アップデートした。今年はこまめにストア版もアップデートするようにがんばるぞい。

wasaviはtextareaの他にcontenteditable属性の付いた要素も編集できるわけだが、そういう要素にどのように中身を埋めていくかはサイトによって異なり、統一されたものはない。そういうわけで、writeasというオプションを用意している。これには以下の値を割り当てられる:

• html — バッファの内容を markdown とみなし、html を構築する（デフォルト）
• div — 各行につき div 要素を生成する
• p — 各行につき p 要素を生成する
• textAndBreak — 各行につきテキストノードを生成し、改行として br 要素を追加する
• plaintext — バッファ全体を単体のテキストノードにする

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] が表示されるようになる
• タブ文字が [cci]^I[/cci] で代替表示されるようになる

となる。この内、行末尾の表示について実装したい。残念ながら、タブ文字の代替表示は難しい。

ここで行末尾を示すために文字 [cci]$[/cci] が用いられるというのは、vi が端末上のテキストエディタだからで、wasavi の場合はもうちょっと表現力があるので別の記号にしたい。

行末尾、つまり改行を示すための記号というとまあだいたいこんな感じだと思う。特に日本産のエディタでこれじゃない奴はないのではなかろうか。あと、MS Word。海外産だと行をパラグラフとみなして、Pilcrowが多いかもしれない。まあどちらでもいいけれど、とりあえず前者を使うことにしよう。

ところで、改行マークを表示することに意味があるとは特に思えない。それが役に立つのは、行末に余計な空白文字を残している、いわばダーティというか、非正規な状態の行を目視で確認したい場合くらいだろう。そういう行を正規化したいのなら目視確認なんてせずに正規表現による全置換すればいいだけの話で、改行マークを表示することに意味はない。また、正規化済みの行は空白ではないグリフの直後に改行があることが自明なわけで改行マークを表示する必要はなく、非正規な状態の行だけその旨を表示するようにすればいいのだが、非正規な行の場合でも本来強調表示すべきは行末の余計な空白文字であって、改行マークではない（vimの場合で言えばlistcharsに対してeolではなくtailだけ設定した状態）。従っていずれの場合でも改行マークを表示しなければならない積極的な理由はないように思える。

と、そう考えればそうなのだが、実は去年はあんまりwasaviの開発を進められなかったのでいまいち内部の構造を忘れかけているのであった。そのリハビリのためにあえて実装してみる。

ということでこうなった。