Next: インダイレクトバッファー, Previous: バッファーの作成, Up: バッファー [Contents][Index]
バッファーのkill(Killing a buffer)により、 そのバッファーの名前はEmacsにとって未知の名前となり、そのバッファーが占めていたメモリースペースは他の用途に使用できるようになります。
バッファーに対応するバッファーオブジェクトは、それを参照するものがあればkillされても存在し続けますが、それをカレントにしたり表示することができないように特別にマークされます。とはいえkillされたバッファーの同一性は保たれるので、2つの識別可能なバッファーをkillした場合には、たとえ両方死んだバッファーであってもeq
による同一性は残ります。
あるウィンドウ内においてカレント、あるいは表示されているバッファーをkillした場合、Emacsはかわりに他の何らかのバッファーを自動的に選択または表示します。これはバッファーのkillによってカレントバッファーが変更されることを意味します。したがってバッファーをkillする際には、(killされるバッファーがカレントを偶然知っていた場合を除き)カレントバッファーの変更に関しても事前に注意を払うべきです。カレントバッファーを参照してください。
1つ以上のインダイレクト バッファー(インダイレクトバッファーを参照) のベースとなるバッファーをkillした場合には、同様にインダイレクトバッファーも自動的にkillされます。
バッファーのbuffer-name
がnil
の場合のみバッファーはkillされます。killされていないバッファーは生きた(live)バッファーと呼ばれます。あるバッファーにたいして、そのバッファーが生きているか、またはkillされているかを確認するにはbuffer-live-p
を使用します(下記参照)。
この関数はバッファーbuffer-or-nameをkillして、そのバッファーのメモリーを他の用途のために開放、またはオペレーティングシステムに返却する。buffer-or-nameがnil
または省略された場合にはカレントバッファーをkillする。
そのバッファーをprocess-buffer
として所有するすべてのプロセスには、通常はプロセスを終了させるシグナルSIGHUP
(hangup)が送信される。プロセスへのシグナルの送信を参照のこと。
バッファーがファイルをvisitしていて、かつ保存されていない変更が含まれる場合には、kill-buffer
はバッファーをkillする前にユーザーにたいして確認を求める。これはkill-buffer
がinteractiveに呼び出されていなくても行われる。この確認要求を抑制するにはkill-buffer
の呼び出し前に、変更フラグ(modified
flag)をクリアーすればよい。バッファーの変更を参照のこと。
killされるバッファーをカレントで表示しているすべてのバッファーをクリーンアップするために、この関数はreplace-buffer-in-windows
を呼び出す。
すでに死んでいるバッファーをkillしても効果はない。
この関数は実際にバッファーをkillするとt
をリターンする。ユーザーが確認で拒否を選択、またはbuffer-or-nameがすでに死んでいる場合にはnil
をリターンする。
(kill-buffer "foo.unchanged") ⇒ t (kill-buffer "foo.changed") ---------- Buffer: Minibuffer ---------- Buffer foo.changed modified; kill anyway? (yes or no) yes ---------- Buffer: Minibuffer ---------- ⇒ t
保存されていない変更について確認を求める前に、kill-buffer
はリストkill-buffer-query-functions
内の関数を出現順に引数なしで呼び出す。それらが呼び出される際にはkillされるバッファーがカレントになる。この機能はこれらの関数がユーザーに確認を求めるというアイデアが元となっている。これらの関数のいずれかがnil
をリターンしたら、kill-buffer
はそのバッファーを殺さない。
このフックは非nil
のinhibit-buffer-hooks引数のget-buffer-create
またはgenerate-new-buffer
で作成された内部バッファーや一時バッファーにたいしては実行されない。
これは尋ねることになっている質問をすべて終えた後、実際にバッファーをkillする直前にkill-buffer
により実行されるノーマルフック。この変数は永続的にローカルであり、メジャーモードの変更により、そのローカルバインディングはクリアーされない。
このフックは非nil
のinhibit-buffer-hooks引数のget-buffer-create
またはgenerate-new-buffer
で作成された内部バッファーや一時バッファーにたいしては実行されない。
特定のバッファーにおいてこの変数が非nil
なら、あたかもファイルをvisitするバッファーにたいして提案するときのように、バッファーの保存を提案するようにsave-buffers-kill-emacs
に指示する。2つ目のオプション引数をt
にセットしてsave-some-buffers
を呼び出せばバッファーの保存も提案する。最後にこの変数をシンボルalways
にセットすると、save-buffers-kill-emacs
とsave-some-buffers
は常に保存を提案する。Definition of save-some-buffersを参照のこと。何らかの理由により変数buffer-offer-save
がセットされると自動的にバッファーローカルになる。バッファーローカル変数を参照のこと。
特定のバッファーにおいてこの変数が非nil
なら、save-buffers-kill-emacs
とsave-some-buffers
は、(バッファーが変更されていれば)ユーザーに確認を求めることなくそのバッファーを保存する。何らかの理由によりこの変数をセットする際には自動的にバッファーローカルになる。
この関数はobjectが生きたバッファー(killされていないバッファー)ならt
、それ以外はnil
をリターンする。