変なエヂタ EMACS

イキナリなんですが, みなさん, EMACS って使いやすいですか？ てゆうか, そもそも使ってますか？ 私は使ってます. 使ってますが, なんつうか, なんでこんなもんがこれほど普及してるんですかね. そこんところはイマイチよくわかりませんね.

最初に EMACS を使ったのはメールを読むためであった. mh-e という elisp の パッケージがリリースされたばかりで, これを使ってメールを読んでいた. まともにエディタとして使い始めたのは, じつは 修士論文を書かねばならなく なって, しかも自分のパソコンがぶっ壊れて新しいのを買う金もなく, しかたなく学校に籠ってX端末から入力せねばならなくなってからである. それまでは, EMACS が目の前にあっても dos の名作エディタ `VZ' をずっと使い続けていた.

当時は日本語 emacs すなわち「ねまくす」といいました. MULE の前身ですな. ねまくすをちょっといじって 3日くらいで, 「これは, 乗り換えるしかない！」と認識しましたね. エディタやシェルを乗り換えるのはけっこう勇気が要ると言われてるが, それは, これらのプログラムがそれだけ本質的で重要なものだということだ. それほど重要であるが故に, ちょっと使えばその優秀さはすぐに判るのかもしれ ん. わしは, 最初に付属の tutorial をやって, あとは, ヘルプコマンドを実行しまくるという方法 で, 使い方を憶えました. 本は一冊も見てません. その結果判ったことは, このプログラムは実はエディタではなかったということ です. EMACS は,

それまで, プログラムというのは片手でマニュアル本を見ながら, もう片方で操作しておぼえてゆく, そういうもんだと思っていたので, 「本が要らない」というのはマジで感動でしたね. そもそも. unix というのは全般的に「本が要らない」つくりの OS であり, 「計算機のことは計算機でカタをつける」という思想が徹底している. なかでも, それが非常に(と, 当時は思えたのよ)徹底しているのが EMACS だった. 呼び出す関数の summary が直ちに得られる. しかも, ある LISP関数の summary を見るために, 関数名を入力 するときも, その関数を評価させるときと同じように名前が補完できるところな ど, 同じ self-documented とはいえ, apple あたりの help なんかとは違うレ ベルで, ドキュメントとプログラムが完全に統合されて存在しているように思われ, 非常に感動した.

しかしそれよりなによりぶったまげたのは, EMACS というのは, 第一に LISP インタプリタなのであり, たまたまエディタなのだ, というところです. EMACS に, 他のエディタと一線を画すところがあるとすれば, まさに, この 変てこな設計でしょう. そして, こういうシンプルで強力な原理, 原則に基づい た製品に, わしは滅法弱いのだ. いや, EMACS はシンプルな原理に基づいてはいるが, EMACS 自体は死ぬ程複雑 ですけど.

実にシンプル！ EMACS では, キー操作(それに, マウス操作も)は全て, LISP 関数の呼出なのだ. アルファベット一文字入力するのにも, カーソルを一マス移動するのにも, 全て LISP 関数が呼び出されている(lisp 風に言えば, 評価されている)のだ. 普通のバッファでキー `a' をタイプすると評価される関数は, 「その文字を挿入する」という LISP関数だ. 

a runs the command canna-self-insert-command:

Self insert pressed key and use it to assemble Romaji character.
我々は, EMACS を使ってテキストを編集しているのではなかったのだ. lispインタプリタにlisp関数を評価させているのである！！ これに気づいたときは, マジでたまげましたね. どひぇー！

`.emacs' でおめにかかる e-lisp こそは, EMACS が理解する LISP だ. e-lisp は, 当然ながら, エディタ向けに作られている LISP なのだが, それでもけっこう本格的な LISP であることにはかわりないわけで, EMACS が発揮する異常な多用途性は, すなわちEMACS が e-lisp インタプリタで あるというところに依るわけだ.

そういう万能なエディタである EMACS ではあるが, デフォルトの設定はあまり にひどいのであり, かつ, その設計もやや現代の環境とは合わなくなっている. 普通の EMACS の使い方で一番しっくり来るのは, kterm か コンソールの上で 実行し, 必要に応じて Ctrl-x Ctrl-z で suspend し, 何か shell command を 実行してから, fg して作業の続き, という形態であろう. root での作業のときは, わしは今でもけっこうこういう使い方をする. 端末窓が一個しか無い場合には, 非常に便利だったわけだが, 窓を何個でも開け る今となっては, いっぺんに 10個もバッファ開いたら, いったいどれがどれや ら皆目判んなくなってしまうのは俺だけではあるまい. しかも, デフォルトの設 定では何個ファイルを開こうが, 窓は一個しか開かないのだ. 基本的に, 端末が一個しか画面が無い時代の設計なのだ. こりゃ具合悪いわい. GNOME の drag+drop でファイルを読み込むことすら出来ない.

実は, X で使っていると, 「もう一個窓を開き, そこにファイルを読み込む」 というのができる. find-file-other-frame という関数を呼べばいい. 

find-file-other-frame: an interactive compiled Lisp function.
(find-file-other-frame FILENAME &optional USER-CODING-SYSTEM)

Edit file FILENAME, in another frame.
May create a new frame, or reuse an existing one.
See the function `display buffer'.
A prefix argument enables user to specify the coding-system interactively.
引数は, ファイル名だ. 普通の find-file よりも, こっちの方がずっと使いやすいはずだが, この関数 は なぜかデフォルトではとんでもなく長い key sequence に割り付けられていて, 「使うな」という感じを醸し出している. 俺は, こいつを Ctrl-x Ctrl-f に割り当てている. find-file-other-frame は, X 以外の環境で使うと, 普通の find-file になる ので, こういう設定でも問題ない. Ctrl-x f は, 普通の find-file に割り当てている.

new-frame という関数も, とても役に立つ. EMACS のプロセスは一個だけど, 新 しい窓ができるというやつだ. info 見ながら操作したい, という時も多かろう. そんなとき, いちいちバッファを移って操作するのか？ switch-to-buffer を呼び出して, 引数を補完しようとすると, 同じような名前 のバッファが 3個くらいあって, どれがどれだか判んなくなったことって無いか？ それとも, 狭い窓を横に割ってやるのか？ それで other-window を使うという. ナンセンスである. さっさと新しい窓を開き, そこで info をみながらやれば全然問題ないわけでして. しかし, この関数はデフォルトではなんだか数字キーを含むミョーな key sequence に割り付けられていたような. わしは, こいつを M-n に割り当てた.

窓がもう一個欲しければ, どうせメモリが余ってるんだからもう一個 EMACS を スタートさせればいい, という意見もあろうが, それは間違っておる. 違うプロセスなので, バッファや, kill-ring や cut-buffer やコマンドのヒストリ が共有できない. だから非常に便利悪いです. それに, 私の環境は, 残念ながらメ モリは余ってません.

他にも苦情はある. せっかく窓を複数開けるのだから, マルチスレッドにしてほし い. 何かでかい LISP パッケージを読み込むと, 他の窓での操作も全部止まるの は具合悪うございます. それから, GNOME の drag+drop に対応して欲しい. って, ソースコードあるんだから, 自分でやれって？そりゃごもっとも. 失礼こきました.

それにしても, こいつが LISPじゃなきゃなあ. もっと簡単にカスタマイズでき るんだろうけど, この言語はいまいち慣れないね.