LoginSignup
4
4

More than 5 years have passed since last update.

elscreen使用中にカレントバッファをkillすると入れ替わり先のバッファが別スクリーンで開いているバッファになってしまう問題への対処

Last updated at Posted at 2014-07-06

tl;dr

環境

問題

例えば、以下のようなスクリーン構成だったとする。現在開いているスクリーンは1番。

[0- *scratch*] 
[1+ a.txt] 

で、スクリーン1でb.txtを開く。

[0- *scratch*]
[1+ b.txt]

ここで、kill-bufferコマンドでカレントバッファ(b.txt)を閉じる。この時、a.txtが代わりに表示されることを期待するが、結果は

[0- *scratch*]
[1+ *scratch*]

こうなってしまう。

スクリーン0で*scratch*ではなく別のバッファを開いている場合、そのバッファに切り替わる。

また、スクリーンが1枚しかない場合、期待通りa.txtが表示される。

原因

elscreenは現在のスクリーン表示状況に合わせてタブやメニューを表示している。その表示を随時更新しているのが、post-command-hookに仕掛けられたelscreen-run-screen-update-hook関数である。

この関数が実行する関数の中でも、elscreen-tab-update関数およびelscreen-menu-bar-update関数が悪さをしているせいで、上記の問題が発生している。

具体的には、上記の関数が中で呼び出しているelscreen-get-screen-to-name-alist関数が"Window History"を書き換えるという副作用を持っているせいで、上記の問題が引き起こされたようだ。

最近のEmacsはウィンドウ毎に表示したバッファの履歴を管理しているらしい。これをWindow Historyという。

kill-bufferbury-bufferでカレントバッファを非表示にした場合、次に表示するバッファはWindow Historyを元に決定されるとのこと。 なので、elscreen-get-screen-to-name-alistがWindow Historyを書き換えるとkill-buffer時の挙動が変化してしまう。

elscreen-get-screen-to-name-alist関数は中でelscreen-save-screen-excursionマクロを使って副作用をキャンセルしようとしている。 そこで、このマクロを書き換えて、Window Historyを復元してやればよい。

4
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
4