いろいろ試してみると、[cci]ping[/cci] では効果がなかった。また、Windows7 ではローカルセキュリティポリシーの設定によって RDP 8.x かそれ未満を使うかを指定できるのだが、8.x を指定しなければ勝手にスリープは起こらなかった。やはり 8.x に問題があるようだ。
これはうちだけではなく普遍的な問題なのか、Windows7 向けの更新プログラムが現在は公開中断されているようだ。なんということでしょう。
MS さん早く直してください。
最近 Windows7 にもたらされた更新の中に、RDP、つまりリモートデスクトップで使用するプロトコルのバージョンを 8.0 に上げるというものがある。これは 7.1 に比べてデータの送信がずいぶん軽くなっているという触れ込みである。そいつは嬉しいじゃないか、ということでいれてみた。
確かに体感的に軽くなっているような気がしないでもない。などと書くと曖昧だけど、いや実際リモートで地デジなんかを見ると、従来はその時々の状態によってはコマ送りになったり音声がノイズまみれになったりすることもあったのがかなり軽減されたりしているので、実際効率は上がっているのだと思う。いいことだ。
しかしいいことばかりではないのだった。
ホスト側は 30 分、インタラクティブな操作を行わないと自動的にスリープするようにしているのである。従来は、その設定の状態でリモートデスクトップに接続した場合でも、それを通したリモート側の操作がホストのスリープを回避するアクションとして認識されていた。しかし RDP を 8.0 にすると無効になってしまう感じなのだ。リモートデスクトップを操作中に予告なく画面が固まり、あれ？ ハングした？ と思うとホストが眠りに入っている。なにこれもうやめてよね！
とりあえず、RDP 以外の手段でホストに定期的にちょっかいを出せば回避できる。たとえば WMP でホスト上のメディアファイルをずっと再生し続けるとか、あるいは単に [cci]ping -t[/cci] するとか。
MS さん早く直してください。
以前 cygwin 上で、Windows Vista 以降の NTFS ネイティブなシンボリックリンクを作るために逡巡したことがあって、一応できたのだが、それは諸々の環境を整えた上で最終的には [cci]cmd /c mklink[/cci] を呼ぶというものであった。
これだとメッセージが mklink のそれになってしまうし、コードページの不整合が起きる（つまり UTF-8 な端末で呼ぶとメッセージが文字化けする）というどうでもいいけどどうでもよくない不都合もある。それを置いても、やはり cygwin の中からコマンドプロンプトベースの実行ファイルを呼び出すのはなんともイケてない。なんとかならないか。
さて Windows 側のシステム環境変数 [cci]CYGWIN[/cci] に設定する値によって、cygwin の動作を制御することができるのだが（ドキュメント）、その中に winsymlinks という項目がある。これを [cci]nativestrict[/cci] という値にすることによって解決できた。ちなみにこの項目は [cci]lnk[/cci]、[cci]native[/cci]、[cci]nativestrict[/cci] の 3 つの値を割り当てることができるのだが、
というわけで、ナウい cygwin で NTFS ネイティブなシンボリックを作成するには
という手順になる。
issue #20 で、検索するとパターンによって無限ループになってタブを閉じるしかなくなるというのがある。特に [cci]|[/cci] とかが危険らしい。なるほどなかなかそんな雰囲気がしないでもない。
これは由々しき問題だ……ということですぐ直そうとしてみたのだけど、再現しない。ということでどういうパターンだと発生するのか聞いているところ。
とりあえず chrome で全テストを通したので github 上のエクステンションを更新。
ハイライトは
になる。2 つだけではあるけれど、かなり手が入った。
vim 同様、V を押すことで行単位の選択もできるようにした。モード名は bound_line。また、bound モード中に bound_line モードに入ると（あるいは逆に bound_line から bound でも）、現在の選択範囲を活かしたまま文字単位・行単位が切り替わるようにした。これも vim と同様。
ところで vi では、空行以外の行においてカーソルを改行の上に置くことはできない。vim もこれは同じだが、ただし visual 系モードに入るとその制限が取り払われる。これはこれでまあそういうものなのかな、ということで一応付けてみたのだが……これ、もしかしてなくてもよくなくなくない？ とりあえずオミットしておこう。クレームが付いたらつける。
それにしてもかなり wasavi.js に手が入った。とりあえずの機能は実装し終えたのでモードを切り替えてテスト三昧の毎日になるのである。
vim の visual モード中に実行できる編集コマンドのうち、大文字のものはほぼ、操作対象が行単位になる。行単位ということは、選択範囲の端点の桁位置は使用されないということだ。行位置だけが意味を持つ。
行単位の操作においては、特に削除処理について文字単位でのそれとの違いを意識する必要がある。具体的には行にマークが含まれる場合である。マークを含んだ行を文字単位で全削除（つまり [cci]^.*$[/cci] を削除）したとしても、マークは空行の先頭位置に収斂され、削除されない。一方、行単位での削除（つまり [cci]^.*\n[/cci]）の場合はマークごと削除される。これは決定的な違いだ。ちなみに削除に対応する undo 情報にはマークも含まれるので、undo すれば行全体とともにマークも復活する。
ところで、最後に使用した選択範囲はマーク [cci]<[/cci] と [cci]>[/cci] で参照することができる。では、visual モードを経由して行単位での削除を行った場合、それらのマークはどうなるのか？ というと vim では削除後もそれらのマークは生き残っているのである。もちろん本来の選択範囲は削除されているので、全然関係ない別の行を指していることになる。これはなんというかバグなのか仕様なのか判別しづらい。
wasavi では行単位で削除を行ったあとは [cci]<[/cci] と [cci]>[/cci] マークは無効になるようにした。
gq
command モードでの [cci]gq[/cci] はオペレータとして扱われ、後続するモーションによって移動したカーソルとの間の領域に「textwidth の幅に収まるよう適切に文字を充填したり適切に改行を挿入する」という処理を行う。ここで、カウントを指定し、かつモーションが [cci]_[/cci] またはそのエイリアス（つまり [cci]gqgq[/cci] または [cci]gqq[/cci]）だった場合、カウントは [cci]gq[/cci] 自体に作用し、相当する行数が再フォーマットの対象になる。
何を言いたいのかというと command モードでは [cci]3gqq[/cci] とか指定した場合、カーソル以下の 3 行を再フォーマットしろ、という意味になる。カウント := 縦方向の行数。
vim では、これが visual モードになると、カウントは textwidth オプションを一時的に上書きする。カウントの意味合いが垂直方向から水平方向に完全に切り替わる。カウント := 横方向の文字数。
これ、良いインターフェースか？ と問われればもちろん全然良くないんだけどどうしたものかなー…。
gv
vim では、command モードでの [cci]gv[/cci] は、最後に使用した選択領域を再びアクティブにしつつ visual モードへ遷移する。ということで wasavi にも実装したのだけど、では visual モード中に [cci]gv[/cci] したらどうなるんでしたっけ？ と思いつつやってみたら、やはり command モードでのそれと同じ動作をした。つまり最後の選択領域の端点と、アクティブな端点は個別に管理しているようだ。
それに倣い、wasavi でも bound モードでのアクティブな選択領域の端点はプライベートなマークを使用するようにした。
選択範囲の指定方法を最適化したい。
今の実装では、wasavi のバッファは DOM そのものであり、バッファ内の行は div 要素であり、選択範囲は span 要素でくくられた領域となる。その状況下で選択範囲が拡張・縮小された場合、当然 span の境界も移動しなければならないのだが、とりあえず一番簡単なのは、再設定に先駆けていったん span 要素を脱皮させ、それから新しい選択範囲をくくりだすことだ。
これはもちろん賢いやり方ではない。選択範囲が複数行で構成されている場合、行ごとに span のくくりだしというループを経なければならないのだ。もっと最適化して、拡張・縮小された領域だけを操作するようにしないといけない。
ということで、そうした。この最適化により、bound モード中のモーション全体が恩恵を受けるのだけど、特に [cci]/[/cci] や [cci]?[/cci] でインクリメンタルサーチを行った際に顕著かもしれない。