カウントを前置した状態で [cci]:[/cci] を押して ex コマンドの入力に移ると初期値が [cci].,.+9[/cci] などとなるようにした。

どうでもいいな。うん。

ついに恐れていた要望が訪れた。

issue #19。つまり、vim の visual モードがほしいというものだ。

visual モードというのは、一般的な GUI が持つテキスト選択の仕組みに似ていて、編集中のテキストの任意の選択範囲を指定するのに用いられるのだが、最大の特徴はその範囲が視覚的に明確に示されるという点だ。visual モードを開始した位置と、現在のカーソルとの間が選択範囲となり、それが例えば反転表示とかされるのである。カーソル移動のために visual モードでは command モードと共通のモーションを使用できるが、オペレーションに関しては visual モード専用の処理が実行される。

何を恐れているかといえば、まず visual モードというネーミングだ。そもそも、vi 自体が ed とか ex とかいったエディタの「visual モード」なのである。完全に被っている。次にそれが必要な決定的な理由がない（と思われる）のも微妙だ。visual モードがなかったとしても編集には基本的には全く問題ないのだ。

しかしまあこれがほしいという要望は多分来るだろうと思っていたし、実際来てしまったので作るわけなのだ。たぶんモード名は変えると思う。

input モード中に backspace や ^H を押した際、カーソル位置より左にある直近のタブ位置からカーソル位置までの文字列がすべて U+0020 で構成されている場合、それらをまとめて削除するようにした。

これは expandtab の状態でタブの代わりに空白の塊が挿入された場合に、それをやはり塊として削除できるようになるので、expandtab によるタブ変換と対になっている機能といえる。この機能は expandtab の状態にかかわりなく、常に有効である（vim がそのようなので）。

ただ塊ではなく 1 つの空白だけを削除したいケースもあるはずで、そういうときは恐ろしくおせっかいな機能と化してしまう。なにか代替となる操作も用意した方がいいかもしれない。まあその辺を実際にどうするかはユーザのレスポンス次第である。

なにはともあれ、とりあえず expandtab 絡みの実装はこれで一段落ということにする。

言うまでもなく vi はモード志向の強いテキストエディタだ。たとえば vi で文字を入力するにはまず input モードに移行する必要があるのだけど、これは総称であって、実際には i、a、o とかを押して入る insert モードと、それから R を押して入る overwrite モードがある。

この overwrite モード、かなり奇妙である。overwrite モードのカーソルが何かの文字の上にあるときに文字を入力すると、それはカーソルの下の文字を上書きする。ただし、改行の上にあるときは改行の前に挿入される。一方 enter を押した場合は常に改行が挿入される。その他にもちょっとした制限があったりなかったりする。

はっきり言ってこのモード、普通にテキストを編集するのにあたっては使うことはまったくないと言っていい。しかし作ってしまったので、expandtab 絡みの動きも overwrite を考慮しないといけないのだった。これが実に面倒くさい。また、あろうことかどうも vim では expandtab+overwrite でタブを入力した時のタブ展開の動きが、expandtab+insert の場合のそれとなんか微妙に違うのである。これ、考えぬいた仕様というよりは、overwrite なんて誰も使ってないのでテストも比較もいまいちされていないのではないかという思いが脳裏をかすめてならない。

それにしても今考えると overwrite モードは作らなくても良かったなーと思うことしきりである。もし wasavi がそれを備えてなかったとしても「なんで overwrite モードねーんだよこのハゲ！」と怒る vi guy は地球上にいないだろう。たぶん Bill Joy さんも許してくれると思う。

vim が持つ expandtab 絡みのさまざまなオプションであるが、とりあえず wasavi には expandtab オプション以外は実装しない。つまり smarttab と softtabstop は実装しない（tabstop、shiftwidth はすでに実装してある）。

で、実際に input モードで tab キーを押した際になにが起こるのかをまとめると:

1. タブ（U+0009）をカーソル位置に挿入する
2. 行頭のインデント中のタブを一旦すべて空白に置き換える
3. 行頭のインデント中のマークをすべて退避する
4. expandtab がオンなら、何もしない。オフなら、行頭のインデントを先頭から走査して、タブに置き換えられる箇所を置き換える。つまり tabstop の字数ぶん連続した U+0020 を U+0009 に置き換える。その過程で、退避したマークのオフセットのつじつま合わせも行う
5. 退避したマークを再設定する

という感じになる。実はこの処理の大部分は、シフトコマンドのそれである。なのでまずその辺を詰めることになる。例えば tab キーを押した際の処理は左や右へシフトを行うわけではない。いわば 0 カウントだけシフトすることになる。という訳でそんな感じのいろいろな修正を施した。

もう少し整理してみる。

vim で input モードで tab キーを押した時に、まず以下のオプションが参照される:

• tabstop
• expandtab

tab とスペースの変換という点で見ると、この 2 つがコアになる。tabstop は tab が最大何文字幅分に伸びるかを指定する。expandtab は、tab キーを押した際に対応する文字数分の空白に置き換えるか、および行頭インデントの最小化（つまり、空白を可能ならタブに置き換える処理）をスキップするかを指定する。

一方で、本質的ではない以下のオプションも参照される:

• softtabstop
• shiftwidth
• smarttab

softtabstop は、「タブ幅は標準の 8 桁から変えたくないけど、インデントの単位は 8 じゃない数値にしたい！！」という向きに応えるためにある。タブ幅自体を変えても気にしないなら、このオプションを弄る必要はない。

shiftwidth は、本来は、< と > コマンドによってシフトする際のシフト量を指定するためのものだが、smarttab の状態によっては tab キー押下時に参照されるときがある。

smarttab は、インデント量をカーソルの位置に応じた文脈で選択させるようにする。smarttab がオンの状態で、カーソルが行頭のインデント領域の中にある時、shiftwidth の分だけインデントされる。smtarttab がオフであるか、あるいはオンであってもカーソルが行頭インデントではない箇所にある場合は、softtabstop、tabstop の順に評価して 0 ではない最初の値を取り出し、それをインデント量とする。

とこのように、expandtab 自体は単純明快なのだけど。字下げスタイルという個々人の好みにものすごく左右されるものにできるだけ対応するための、付加的なオプションのおかげで全体的になんだかわよくわからないものになってしまっている。

さらに cpoptions オプションの設定によって微妙に部分的な動作が変わったり、あるいは前の記事の通り backspace オプションが絡んできたり、:retab コマンドの動作にも影響したりする。カオスすぎる。

issue #16 の、vim の expandtab を実装してよというリクエスト。

expandtab がオンの状態だと、input モードで tab を押した際、タブそのものではなくタブ幅に応じた適当な個数の空白が挿入される。また、> や < でシフトした際、通常はタブで置き換えられるなら置き換える（つまり ts=8 で sw=4 の状態で 2 回シフトすると、インデントは 1 個のタブになる）のだが、その処理を迂回して常に空白でインデントするようになる。

他にも影響があるところがあるかも知れない。実は個人的にこのオプション使ったことがないので、よくわかっていないのだった。インデントを常に空白で行うというのはなんというか富豪的である。貧乏人は普通にタブを使うのだ。

また、間接的に backspace オプション、retab コマンドとも関連する。これらとセットじゃないとやはり実用上は辛いかもしれない。というわけでフルに実装するとけっこうかなり面倒な代物なのだった。

ということを issues やりとりしたら、とりあえず単にインデントを空白で行う処理だけでもいいんじゃね？　みたいな話でまとまったので、そういう方向でやってみよう。