lifeLOG + REPOsitory: Emacs のウィンドウを水平方向に分割する

横 80 桁の呪縛

Emacs との出会いはキャラクタ指向のパソコン上でのことだったこともあり、GUI ベースのものを使うようになっても、その横幅はこれまでずっと 80 桁と決めてきた。「三つ子の……」ということわざを引き合いに出すまでもなく、ごく初期に覚えたことは身に染み付いて消えないのだ。

Emacs のウィンドウを垂直方向に分割することも、ごく初期に覚えたことの 1 つ(split-window-vertically)。キャラクタ端末上の Emacs で複数のファイル(とバッファ)を切り替えて使うためには必須だったし、何より 2 つのファイルの内容を同時に表示できるというのは当時は画期的なことだったのだ。

一方で、ウィンドウの水平方向への分割(split-window-horizontally)についてはほとんど使ったことがなかった。機能としての存在は(ずいぶん前から)知っていたと思うけれど実用性を認めていなかったのだ。実際のところ、キャラクタ端末は言うに及ばず、GUI ベースでも VGA や XGA 程度の画面では 80 桁の画面を複数並べられるほどの横幅はない。

不思議なもので 30 インチのシネマを使うようになっても、その横に 27 インチの iMac を並べるようになっても、ずっと Emacs のウィンドウは 80 桁のもの 1 つだった。ずっとそうでなくてはならない、と思い込んでしまっていたのだ。

呪縛を破る

呪縛(不合理な思い込み)を打破するためには、実際に見ることが一番だ。わたしの場合、それは Emacs の活用術を特集したある雑誌のページだった(→「WEB+DB PRESS Vol.58」)。記事の内容はウィンドウのサイズとも分割とも全然関係ないものだったが、その中に水平方向に 2 分割された Emacs ウィンドウのスクショが掲載されていた。

それを見て目からウロコが落ちる気がした。「あ、そうか。横にも分割できるのか。」「今の画面サイズなら実用になるかも。」「けど、描画が遅いんじゃないかな。」「どうかな、昔とは CPU のパワーも桁違いだから。」「やってみればわかるだろう。」

やってみた。結論から言って、描画がモタつくようなことはない。スクロールして、画面が上からヌルヌルと描かれていくなんてことはない。

ちなみに、水平方向への分割は Ctrl-x 3 に割り当てられている。水平方向の分割が Ctrl-x 2 だから覚えるのにも苦労はない。

水平方向に分割した Emacs ウィンドウ
水平方向に 2 分割

ウィンドウの横幅は 80 桁 x 2。2 つのファイルが同時に表示されている。シネマの画面にはまだまだ余裕がある。
水平方向に 4 分割

ウィンドウの横幅は 80 桁 x 4。最左の画面は縦方向にも 2 分割している。都合、5 つのファイルが同時に表示されている。シネマの画面もほぼ一杯になっている。

複数ウィンドウ vs ウィンドウ分割

単に複数のファイルを同時に表示するだけなら別の方法もある。今の Emacs ならウィンドウを複数開くこともできる。複数ウィンドウに比べて、ウィンドウ分割が優れている点は、単一のキー操作(Ctrl-x o)を繰り返すだけでフォーカスするバッファを切り替えられることにある。慣れてくればほとんど自動的に指が動いてくれる。

Xcode のエディタも複数のウィンドウを開くことができるが、キー操作、それも単一の操作だけでウィンドウを切り替えることはできない。

ま、80 桁 x 4 はちょっと極端すぎるかもな。画面が一杯になって他のウィンドウが表示できなくなる。実用性を考慮すると、80 桁 x 2 ぐらいがちょうど良いのかも。