GNU screenのvisual bellがvimやlessと干渉していた

地味に不便な不具合

Terminal emulator使いにとっては欠かせないterminal multiplexerのGNU screen (今時はtmuxとかneercsとかmtmなんだろうか)。

そんなscreenの内部でlessやvimを使っている時、fileの先頭や末尾にcursorが到達した後もうっかりkeyを押下し続けているとterminal emulator全体がしばらく固まってしまう現象に悩まされていた。硬直時間はkeyを押下していた時間 (=入力文字数)に比例して長くなるので、repeat speedを上げ、repeat delayを短かく設定している (=短時間に多くのkey repeatが発生する)環境では顕著だった。

いろいろと試してみた結果、screenが提供しているvisual bellの機能を切れば問題が発生しないと分かった。

Visual bellの切り方 (audible bellへの戻し方)

* ~/.screenrcにてvbell offの行を追加する (或いはcomment outする)。

* 起動中のscreenでは、C-a : (prefix + :)でvbell offを実行する。

Visual bellについて

音ではなく「目で見 (え)るベル」という意味合い。

pager (lessとか)やeditor (vimとか)でfileの先頭或いは末尾に達してそれ以上はscrollできない時とか、何かしらのactionをcancelした時など、eventが発生した時に音を鳴らすのではなく、かわりに画面を瞬間的に反転させたり、最上行・最下行を反転させたりする機能である。

今回の問題は以下のような機序で発生するものと推察する:

* visual bellをonにしたscreen内部でvimやlessを使っている時、fileの先頭や末尾に到達したなどの理由でvisual bellが発動すると、screenがそのための処理をする

* その最中にkey inputが継続すると、screenはbufferに蓄えられていたその一つ一つに対して馬鹿正直にvisual bellの処理を実行する

* key inputが大量だった場合、結果としてterminal emulator全体をfreezeさせてしまう

* 何れ処理が終わると復帰し、その後に入力されていたkeyに反応しはじめる

問題の原因特定に至る試行過程

* Editorやpagerを疑う → lessとvimでは発生したが、lv (Powerful Multilingual File Viewer, lessのかわりに使えるpager)やnano (editor)では発生しなかった

* Terminal emulatorを疑う → Xfce4 terminalを使っていたので、xtermなどで実験した

* screenを疑う → Xfce4 terminalでもxtermでもscreenを使っている時のみ発生したのでscreenが怪しいと思い始めた

* visual bellを疑う → 何となく「visual bellを切ったらどうなるのか」と思い試してみたら当たりだった

その他の対処法

著者の使い方ではvisual bellを切るのが最も簡単な手段だったので採用したが、他にも幾つか方法は考えられる:

* screenから乗り換える → tmuxなどでは試していないので不明

* key repeatのspeedを下げ、delayを大きくする

* lessではなくlvを使う、vimではなくnanoを使う