under the control

コードポイント U+0000 から U+001F はいわゆる制御文字とかコントロールコードと呼ばれる文字を表す。

この中で、今日日プレーンテキスト内によく使われるのは CR、LF、TAB、FF、VT くらいで、その他の文字はほとんど使われることはないのだけど、それでもなお存在はしている。

vi では、入力モード中や ex コマンド入力中に特別なシーケンスを用いて制御文字を入力することができる。まず ^V を押し、次に入力したい文字を押す(U+0000 から U+001F までは ^@ から ^_ に対応している)。

textarea に書き込むテキストにもまた、それらの制御文字が必要だとは思えないが、wasavi でも ^V によるエスケープを用いた入力に対応している。ただし、vim のように ^V + 8 進数によるコードポイント入力には未対応。

さて入力できたとして、それをどう表示するかが問題になる。本来は表示上も ^K とかいう形式にしたいのだが、wasavi では 1 行の表示はブラウザ任せなので、なかなかそこまで制御できない。制御文字に対応する部分を
^K
のような形にすればいいのだが、まだそこまでやっていない(編集するテキストが span によって分割されていることを前提にするのは、たぶんシンタックスハイライティングの実装とセットになるので)。

そこで、Unicode には Control Pictures というものがあるので、とりあえず wasavi が管理するバッファ内の制御文字は U+0000 -> U+2400 みたいな変換を施して保持している。もちろんバッファ内のテキストを外部に出力する際は本来の制御文字に逆変換する。

ただ、これだと Control Pictures の各文字が等幅じゃなかったり、ブラウザによって見た目が違ったり、下手すると表示されなかったり、制御文字ではなく U+2400 ~ U+241F そのものを扱えなかったりするわけなので、まあ本当に「とりあえず」の仕様だ。

ところで「等幅」の読みって「とうふく」だと長年思っていたら、なんかググると「とうはば」らしいですよ。大ショック。

quit, wq

ex コマンド quit は vi を終了させる。
q[uit][!]

コマンド名に文字 ! が後続していない場合:

  • 最後に完全な保存が行われてからバッファが変更されていれば、エラーにする
  • vi の起動時に与えた引数リストのうち、現在参照しているファイル以降の編集待ちファイルが待機しており、かつ、最後に実行したコマンドが quit、wq、xit、ZZ のいずれでもない場合は、エラーにする

コマンド名に文字 ! が後続している場合は、編集セッションを終了する。

引数リストというのは、
$ vi foo.txt bar.txt baz.txt
などというコマンドラインで vi を起動した際に与えたファイル名の配列 [foo.txt, bar.txt, baz.txt] のことだ。さて、foo.txt の編集中に :q する。すると、(vim の場合)2 more files to edit などというエラーになる。残りの bar.txt と baz.txt どないすんねんと怒っているわけだ。ただ、:q してさらに :q した場合などは、なんやそないに終了したいんなら言うとおりにしたるわ、と妙にユーザーフレンドリーな振りまいをし、終了する。

なお wasavi は引数リストをサポートしていないので、このルールは関係ないし関西弁でしゃべったりもしない。

 * * *

というわけで write と quit コマンドがあるのだが、実際にファイルを編集、特に数行編集して即 vi を抜けるなんていう場合、2 回 ex コマンドを投入したり、あるいは :w|q と打つのが面倒だということなのか、wq というコマンドが用意されている。

wq は write をまず実行し、成功したら quit を実行するという処理をひとまとめにして行う。wq のシンタックスは write と同じである。

See the write

ex コマンド w、q、wq、x。

これらのコマンドは、編集中のバッファの内容を書き出したり、vi 自体を終了したり、その 2 つのの動作をひとまとめに行ったりする。バッファの内容を書き出すことと vi を終了することには、本質的には強い関連性はないのだけど、実践的なコマンドの使用頻度を鑑みたのか、ex コマンドの体系では結び付けられている。

基本となるのは w(write) コマンドと q(quit) コマンド。

write
[addresses]w[rite][!][>>][file]
w コマンドはバッファの内容をファイルに書き出す。

通常、addresses を明示せずに ex コマンドを実行した場合、対象となる行は単にカレント行であるが、write コマンドは global や v コマンドとともに規定値がバッファ全行になっている。

ファイルへの書き込み
w コマンドのコマンド名に空白文字が後続していない、または file が文字 ! で始まっていない場合は、書き込みはファイルに対して行われる。

  1. 引数 >> が指定されており、かつ file がすでに存在している場合、バッファの内容はそのファイルの内容を置き換えるのではなく、追記される。>> が指定されているにもかかわらず file が存在していない場合、>> が指定されなかったものとして振る舞うか、書き込みが失敗するかは未定義である。
  2. readonly オプションがセットされている場合、書き込みは失敗する。
  3. file が指定されているが、それがバッファに結び付けられたファイル名ではなく、かつ file が存在する場合、書き込みは失敗する。
  4. file が指定されなければ、バッファに結び付けられたファイル名が用いられる。バッファにファイル名が結び付けられていなければ、コマンドは失敗する。
  5. バッファに結び付けられたファイル名が用いられ、かつそのファイル名は file または read コマンドによって変更されたものであり、かつそのファイルが存在する場合、書き込みは失敗する。一旦書き込みが成功した後は、後続する書き込みはこの理由で失敗してはならない(再びファイル名が変更されない限り)。
  6. バッファ全体を書き出せず、かつ書き込み先ファイルが存在する場合、書き込みは失敗したとみなす。

コマンド名に ! が続いている場合、ルール 1.、2.、3.、5. において書き込みは強制的に行われる。

writeany オプションがセットされている場合、ルール 2.、3.、5. において書き込みは強制的に行われる。

この他の実装依存の条件判定により書き込みが失敗することもある。

バッファが空である場合、空の内容で書き込みが行われる。

書き込まれた行数とバイト数の情報がメッセージとして表示される必要がある。

プログラムへの書き込み

コマンド名の後に 1 文字以上の空白が続き、かつ file の先頭が文字 ! である場合、文字 ! の後の残りの文字列は、文字 %、#、! について展開が行われる(展開の詳細は省略)。

ex/vi は shell オプションで指定されるプログラムを起動し、2 つの引数を渡す。1 つめは -c である。2 つめは write コマンドへの引数(展開済み)が単一の引数として渡される。バッファ内の指定された行は起動したプログラムの標準入力へ書き込まれる。プログラムからの標準エラーや標準出力があれば、print コマンドの出力のように表示される。出力の最後の文字が改行でなければ、改行が出力される。

write コマンドに続く文字 ! はバックスラッシュによって効果を打ち消すことができる。

Continue reading

finding a max z-index

wasavi の新しいビルドはだいたい週末にここにアップし、さらに某掲示板でアナウンスしているわけなのだが、その中に

クロームでふたクロ使ってると
フローティングのテキストエリアの下にviの編集ウインドウ開いちゃうね
調節する方法あるのかな
これわさびで入れてみたよ

というリプライがあった。ふたクロというのはその某掲示板向けの Chrome 用拡張だ。

さてこれは要素の上下関係の問題だ。具体的には、2 つの要素のそれぞれの z-index プロパティの値の関係だ。確認してみると、ふたクロが生成する textarea のその親となる form の z-index は 2000000013 とかそんな感じだった。20 億飛んで 13。一方で、wasavi が生成する iframe には 16777215 すなわち 0x00ffffff を入れている。したがって wasavi のほうが隠れるというわけだ。

直接的には、20 億飛んで 13 を超える z-index 値、たとえば 0x7fffffff を割り当てるだけの話だが、そんなんでいいのか? という気も。まずこの値は経験則的な最大値でしかない。32bit バイナリでブラウザを動かして、z-index がとりうる値は負の値を含む数値で……なんてところだとまあ最大値はたぶんこれだろう程度のものだ。しかし CSS2.1 の仕様では z-index の最大値には特に記述がない。すると、もしかしたら 64bit バイナリなブラウザではさらに大きな z-index 値を指定できる可能性もなくはないということになる。そうすると 0x7fffffff を指定したところで意味がない。

実はある時期までは、wasavi の起動時に全要素を舐めて、その時点での最大の z-index 値を算出し、それを超える値を wasavi に与えていた。これならどの環境でも問題ない。手法としては、やはりこれが正道だ。しかし、全要素を舐めるわけなので当たり前なのだが、算出処理がとても重いのだ。100ms オーダーで時間を要する。

次善の策として、全要素ではなく、対象となる textarea 要素をその親へ遡った部分ツリーだけを算出の対象にするという方法もある。これならまあせいぜい数 10 個の要素を舐めるだけの話だ。ただこれだと必ず最大の z-index を得られるわけではないんですけどね……まあしかたないかな。

そういうわけでそう修正。

!?

set me free

ex コマンド、set のテスト。
set [option[=value] | nooption | option? | all]*
単純なコマンドに見えて、意外に奥が深い。

引数がまったくない場合、デフォルトの値から変更されているオプションが表示される。

set

引数が all を含む場合、すべてのオプションが表示される。posix では all が排他的とは定義されていない。つまり、:set report all などと入力すると report の値を表示し、次に全オプションを表示する……ような実装が定義にもっとも素直に従っている。vim もそう動作する。これに対し、wasavi では最初に引数を走査し、all を含んでいたら他の引数は無視し、単に全オプションを 1 度だけ表示する。

set all

オプション名に続き、文字 ? を入力した場合、現在のオプションの値が表示される。? とオプション名の間には 0 文字以上の空白を挟むことができる。2 値タイプのオプションでは、現在のオプション値を表示するのに ? の入力は必須である。2 値タイプ以外のオプションでは、? を付けても付けなくても、代入式でない限り現在の値を表示する。

2 値タイプのオプションが set option の形式で指定された場合、option の値はオンになる。一方、set nooption の形式ではオフになる。2 値タイプ以外のオプションで nooption 形式を指定するとエラーになる。

2 値タイプ以外の、数値や文字タイプのオプションでは set option=value 形式で値を与えることができる。このとき、value 内に空白を含めるには、空白の前にバックスラッシュを置く必要がある。1 文字以上の空白は引数の区切りとみなされる。これにより、単体の set コマンドで複数のオプションをセットしたり表示したりできる。オプション名と = の間には 0 文字以上の空白を含めることができる。

substitute!

ex コマンドの華、s コマンドのテスト。
[addresses] s[/pattern/replacement/[options][count][flags]]

指定された範囲 addresses の各行について、正規表現 pattern にマッチする箇所を replacement で置換する。pattern を囲む区切り文字は / の代わりに \、|、改行、” 以外の非アルファベット文字を用いることができる。\ は区切り文字や \ そのものなどの特殊な文字をエスケープすることができる。

pattern、および replacement の直後の、コマンドラインの末尾となる区切り文字は、省略することができる。pattern と replacement が両方省略された場合、最後に実行された s コマンドが繰り返される。pattern が指定されないか空の場合、vi 全体で最後に使用された正規表現が用いられる。replacement が指定されないか空の場合、pattern にマッチする箇所は空文字列で置換される。replacement 全体が % である場合、最後に s コマンドで使用された置換パターンが用いられる。

replacement 内でのキャリッジリターン(ex モードでは \、open/vi モードでは ^V によるエスケープで入力)は、入力箇所で行を分割してバッファ内に改行を生成することを意味する。キャリッジリターン自体は無視される。

options が文字 g(global を意味する)を含んでいる場合、行内において pattern にマッチする範囲が互いに重ならない形式ですべて置換される。

options が文字 c(confirm を意味する)を含んでいる場合、確認モードになる。pattern にマッチした箇所が画面に現れる。vi はユーザーからの反応を待つ。肯定的な応答(y など)が入力されると置換が行われる。他の入力では行われない。

検索方向が未保存の場合、s コマンドはそれを「前方」にセットする。

s コマンドの亜種として & コマンドがある。& コマンドは
s/pattern/replacement/
として置き換えられる。このとき pattern および replacement は前回の s、&、~ コマンドで使われたものを用いる。

もうひとつの亜種として ~ コマンドがある。~ コマンドは
s/pattern/replacement/
として置き換えられる。このとき pattern は vi 全体で最後に使用された正規表現、replacement は前回の置換(&、~ を含む)で使われたものを用いる。

コマンド終了後、カーソル位置は、置換が行われなかった場合は変化しない。置換が行われた場合は、最後に置換が行われた行の、最初の非空白文字に置かれる。

replacement の書式 

文字 &(magic オプションがセットされていない場合は \&)は、pattern にマッチし置換されるべき文字列を示す。文字 ~(magic オプションがセットされていない場合は \~)は前回の s コマンドで使用された replacement を示す。\n(n は整数)は、pattern で指定される後方参照式に対応するものを示す。n は後方参照式の出現インデックスを示す。対応する後方参照式がない場合、\n は空文字で置き換えられる。

\l、\u、\L、\U は置換文字列内の要素(リテラル、&、\n)の大文字小文字を操作する。\l と \u は後続する 1 文字の大文字小文字を操作する。\L と \U は後続する文字列を \e または \E が現れるか、置換文字列の最後まで、大文字小文字を操作する。

この他の文字はその文字そのものとして扱われる。

……だそうです。

print and list

デフォルトの ex コマンド、print。このコマンドの書式は:
[addresses]print [count][flags]
addresses は前の記事の通り。

コマンド名 print は最短で p まで省略できる。

count が指定された場合、addresses で指定された最後のアドレス + count – 1 というアドレスが仮想的に生成される。つまり、1,2p3 は 1,2,4p とみなされる。アドレスは末尾から必要な分だけ取られるルールにより、最終的に 2 行目から 4 行目が対象になる。

flags は、コマンド実行後にカレント行をコンソールへ表示する際の細かい動作を指定する。+-#lp のいずれかの文字の連なりで指定する。l または p が指定されたとき、コマンド実行後のカレント行をコンソールへ出力する。これらの違いは:

  • p(print): 普通に表示する
  • l(list):
    • 特定の文字(\a、\b、\t、\n、\v、\f、\r、\)はそのエスケープシーケンスの形で表示する
    • 制御文字のような表示できない文字のうち上記にないものは、\ のあとにその文字コードを 3 桁の 8 進数で表示する。ただしタブ文字だけはそのまま表示する
    • 行の末尾には $ を表示する。行内の $ そのものは、\$ と表示する

だいたいこんな感じである。

# は表示する行の前に行番号をつける。

+- は表示される行を上下にずらすためのオフセットを指定する。+ は 1 行下へ、- は 1 行上へ。

ただこれら、特に flags は、vi を vi ではなく ex として使っている場合にはそれなりに役立つのだろうけど、ビジュアルモードでははっきり言ってまったく使う必要はない。vim においても、#lp のみ認識、list 表示は上記の posix の定義には従っていない(その代わり色分けとかはする)などけっこう違いがある。

wasavi は上記の仕様にだいたい従っているが、posix の定義では flags の各文字は空白を挟んでもよいのに対し、必ずひとまとまりにして指定する必要があるという違いがある。めんどくさいので直すつもりもない。まあフラグの間に空白を挟めないと明日おかーさんが死んでしまうんです! なんとかしてください! などと詰め寄られたら考えないではないが……。

map extension #2

map された lhs が rhs へ展開される際、オプション remap が有効な場合、rhs もまた map 対象となる。すなわち、再帰が発生する。
:map! Q Q_key_pressed
などと定義し、テキスト編集中に Q キーを押したりすると、恐ろしいことが起きる。

再帰を収束させるために、vim においてはオプション maxmapdepth の数値が参照される。デフォルトの値は 1000 である。これ以上の再帰は発生しないようになっている。wasavi でもソース上は再帰の上限があり、それ以上は再帰が発生しない。ただしオプションとしては公開していない。値はとりあえず 100 固定。

再帰を発生させない map を行うには、vim では map の代わりに noremap を使う。しかし前の記事にも書いたが、あまりほいほいと ex コマンドを新設したくない。そこで、昨日の記事で考えたシンタックスに則り、

  • remap の発生する(正確には、オプション remap によって動作が変わる)map
    :map! Q Q_key_pressed
  • remap の発生しない map
    :map! [noremap] Q Q_key_pressed

というような書き方にしようと思う。

またもや vimmer から殺意を向けられそうではあるが。

map extension

例によって map コマンドのテスト。

テストといいつつ、新しい機能なのだけど。ピュアな vi が備える map の機能はかなりストイックである。map の一覧を表示するか、新しく定義するかの 2 パターンしかない。

  • map の全定義を削除する
  • すでにマップされたストローク lhs の検索

あたりはあってよいと思うが、ない。まあ map なんて exrc で一括で行うものだろうし、vi にこれらの機能を埋め込むより exec 編集したほうが早いじゃん、ということなのだろう。

さてこういうパターンの場合、vim はほぼ 100% 実装済みだったりする。定義の全削除は mapclear、lhs の検索は rhs を省略した map の実行といった具合だ。

ただ、map の検索はともかく、全削除のためだけに新しい ex コマンドを新設するのはどうなのかなーと思う。なんとか map のシンタックス内で完結したほうがいいのではないか?

map のシンタックスは、:map[!] [lhs rhs] である。lhs と rhs は両方を常に指定しないといけない。lhs と rhs は空白文字列で区切られる。lhs と rhs のそれぞれで空白文字を含める場合は CTRL-V でエスケープする必要がある。

これを踏まえた上で lhs が特別な値であった場合に、rhs を引数として特別な動作をさせたい。なおかつ特別な値というのは、vi コマンド列としてはエラーになるものでなければならない。そうしないと、その文字列に対するマッピングができなくなるので。

ということで考えてみると、\[\w+\] を使えばいいんじゃないかな。vi のコマンドでは [ のあとには [ が続くに決まってる(vim はここでもいろいろ拡張しているが)のだ。それから、lhs と rhs の両方指定制限は取り払う。そうすると、

  • マップの全削除 :map [clear]
  • マップ内の lhs のうち指定の引数で始まるもので検索し表示 :map Q

みたいな感じになる。この例では [ も ] もリテラルであり、そのままこの通り書く。

vimmer には「死ね!」って言われそうだけど、とりあえずこんな感じで組んでみる。

map, map, map

ex コマンドの map をテストしている。map コマンドは、任意のキーストロークをそれに対応するまったく別のストロークへ透過的に変換するためのルールを指定する。

:map[!] [lhs rhs]

あるいは何も引数を指定しない場合、現在定義されているルールの一覧を表示する。vi には 2 つのマップがあり、それぞれコマンドモード、テキスト入力モードで排他的に使用される。テキスト入力モードのマップを対象にするには、map! と指定する。なお vim にはもっといろいろなモード用のマップが用意されているが、wasavi は vi に則って、やはり 2 つのマップだけを備える。

で、これを実装する際の話として。まず仮に lhs、つまり変換元キーストロークが高々 1 キーなら話は簡単である。押されたら変換関数を通して変換する。これが最も簡単なパターン。

次に難しいのは、lhs が複数のキーストロークであった場合。:map qq 3w みたいな。これは、変換関数に状態を持たせるようにすればいい。

次に難しいのは、変換ルールに曖昧なものがあった場合。たとえば、
:map q 1G
:map qq G

みたいな。どうなるか想像できますか? q を押すとバッファ先頭へ、qq を押すとバッファ末尾へジャンプするつもりの定義だ。

このような曖昧な定義に対してどう振る舞うかを、posix は未定義のままにしている。つまり曖昧な定義をエラーにする vi があってもいいし、よきに計らう vi があってもいいということだ。エラーにするのは簡単だが、よきに計らうにはどうすればいいだろうか?

この定義が有効な状態で、まず q を押す。この状態では、ユーザはバッファ先頭へ飛びたいのか? それとも末尾か? は判断できない。そこで、タイマを仕掛け、1 秒後に 1G へ変換されるようにする。つまり q 単体の入力に対する変換が行われるようにする。また、1 秒以内にキー入力があった場合:

  • タイマを仕掛けていたら、それをキャンセルする
  • 新しいキー入力を加えた上で新しい仮変換候補を抜き出す
  • 抜き出した結果、新しいキー入力を加える前の仮変換候補が確定したら、それを実行する
  • そうではなく、新しいキー入力を加えた後の変換候補が 1 つに絞られれば、その変換候補を確定し実行する
  • そうではなく、新しいキー入力を加えた後の変換候補が複数あれば、変換候補の最初のものに対して 1 秒後に確定・実行されるようにタイマを仕掛ける

みたいな感じにする。