wasavi が起動する際、最小の横幅・縦幅というものがあり、横の最小幅は 320px ということになっている。

このくらい幅が狭いと、ステータスラインに何かメッセージを表示する際に、その長さによっては後ろが隠れてしまうことがある。

これを解決するために、いわゆる marquee 的な動作をさせるようにしてみた。的な、というか、実際に marquee 要素で囲むのである。21 世紀も17年過ぎて marquee 要素を使うとは思わなかった…。

この marquee 要素、いつ廃止されてもおかしくない状況なのだが、とりあえず今のところは Chrome でも Firefox でも使える。ただし Chrome においてはかなりスムーズに動くのに対して Firefox ではかなりガックガクだ。

まああんまり気にしないことにしよう。

ex の executor はかなり書き換えたわけだが、一方で vi コマンドの executor というのも一応ある。これは ex ほど大規模ではなくて、単に vi コマンドの文字列をキー入力キューに挿入するだけだ。この機能は [cci].[/cci] コマンド及び [cci]@[/cci] コマンドが利用している。つまりいわゆるマクロ機能に相当する。

今回コマンドの実行が非同期になったことで難しくなったのは、マクロの実行が完了したタイミングが取れないということで


executeViCommand('2w');
doSomethingAfterExecute();


ということができない。そこで、キー入力の最後に特別な擬似キー [cci]*macro-end*[/cci] を付加するようにした。なぜマクロ完了のタイミングが重要なのかといえば、カウントというものがあるからだ。[cci].[/cci] の場合は実行する vi コマンド列がカウントを内包しているのであんまり関係ないのだが、[cci]@[/cci] の場合はそうではない。

そういうわけでこのマクロ実行完了を表す擬似キーを使う。対応するコマンドハンドラ内でカウントを見て、必要なら再度コマンド列をキー入力キューに充填したりすればいい。ところでそのハンドラは normal モードにしか存在しないので、マクロ実行完了時のモードもまた normal モードじゃいけない。つまり他のモードの場合は [cci]escape[/cci] キーを再充填するなどの処置も必要。

それから、[cci]@[/cci] コマンドというのは指定したレジスタの内容を vi コマンドとして実行する機能なのだが。そうすると今回施した修正の元、たとえば [cci]@a[/cci] という文字列がレジスタ [cci]a[/cci] に格納されている状態で [cci]@a[/cci] を実行すると実質的な再帰が起こってしまう。ちなみに vim 7.4 (2013 Aug 10, compiled Nov 24 2016 16:44:48) で試したところ、固まってしまった（固まらない時もある。よくわからない）。

というわけで、[cci]@[/cci] コマンドのもとで vi コマンドを実行している際は同じレジスタを使った [cci]@[/cci] コマンドを入れ子で使えないようにした。入れ子でなければいいので、@a が @b を呼び、それが @c を呼び…ということはできる。

ぼちぼち Selenium でテストし始める。

ところで Selenium でテストする際、ブラウザの console 出力を得たい時がある。…のだけど、いまいちそのへんのドキュメントが整備されていない気がする。javascript バインディングの API はドキュメントがあるが、これはあくまでリファレンスであってハウツー的なものはほとんど書いてない。

いろいろ調べてみたところ、

const webdriver = require('selenium-webdriver');
const chrome = require('selenium-webdriver/chrome');
:
:
var loggingPrefs = new webdriver.logging.Preferences()
loggingPrefs.setLevel(
webdriver.logging.Type.BROWSER,
webdriver.logging.Level.ALL);

var driver = new webdriver.Builder()
.withCapabilities(webdriver.Capabilities.chrome())
.setChromeOptions(options)
.build()
:
:
driver.manage().logs().get(webdriver.logging.Type.BROWSER).then(log => {
// log は Entry インスタンスの配列で、
// 各要素の message プロパティに console 出力の各行が格納されている
});

という感じでいいようだ。message プロパティは前後にソースファイル名や行番号などが付加されていたりするので、そういうものを削ぎ落とす加工は必要。

長い時間をかけてちくちくいじっていたものが終結しつつある。キーボード入力から vi コマンド / ex コマンドの実行、その実行の完了を保証するシーケンスポイントまでの一連の関数呼び出しが Promise の連鎖によって行われるように修正した。とても疲れた。

これにより、従来あんまり綺麗な形で実装していなかった非同期処理を、それを必要とする関数内に局所的に閉じ込める形にできて見通しが良くなった。例えばクラウドに対する読み書きの場合は、それを担当するのは ex コマンドのハンドラなのだが。応答が複数回来るので、一旦途中で ex 仮想マシンの実行を中断し、wasavi 側のグローバルなメッセージハンドラで受けて、適宜再開する…のようなことをしていた。バックエンドに対するメッセージは基本的に送信と応答の 1 回のやり取りで完結するので複数のやり取りに対応できないからだ。とても不自然。

これを、ex コマンドハンドラ内で Promise を生成し、新規に開いたメッセージポートを通して複数回のやり取りをし、すべてが完了したら resolve() するようになった。とても見通しがいい。

ex コマンドのエグゼキュータも Promise ベースで動作するように書き直した。疲れた。

マップマネージャもまた Promise を使用するように完全に書き直した。これもまた疲れた。

疲れすぎてもう海に還りたい。