| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
バッファ（buffer）は、編集するテキストを収めている Lispオブジェクトです。 バッファは、訪問しているファイルのテキストを保持するために使われますが、 ファイルを訪問していないバッファもあります。 一度に複数のバッファが存在してかまいませんが、 ある時点ではたった1つのバッファがカレントバッファ （current buffer）として区別されます。 ほとんどの編集コマンドは、カレントバッファの内容に作用します。 カレントバッファを含む各バッファは、ウィンドウに表示されることも されないこともあります。
| 26.1 バッファの基本 | What is a buffer? | |
| 26.2 カレントバッファ | Designating a buffer as current so primitives will access its contents. | |
| 26.3 バッファ名 | Accessing and changing buffer names. | |
| 26.4 バッファファイル名 | The buffer file name indicates which file is visited. | |
| 26.5 バッファの変更 | A buffer is modified if it needs to be saved. | |
| 26.6 更新時刻の比較 | Determining whether the visited file was changed | |
| "behind Emacs's back". | ||
|---|---|---|
| 26.7 読み出し専用バッファ | Modifying text is not allowed in a read-only buffer. | |
| 26.8 バッファリスト | How to look at all the existing buffers. | |
| 26.9 バッファの作成 | Functions that create buffers. | |
| 26.10 バッファの削除 | Buffers exist until explicitly killed. | |
| 26.11 間接バッファ | An indirect buffer shares text with some other buffer. | |
バッファ（buffer）は、編集するテキストを収めている Lispオブジェクトです。 バッファは、訪問しているファイルのテキストを保持するために使われますが、 ファイルを訪問していないバッファもあります。 一度に複数のバッファが存在してかまいませんが、 ある時点ではたった1つのバッファがカレントバッファ （current buffer）として区別されます。 ほとんどの編集コマンドは、カレントバッファの内容に作用します。 カレントバッファを含む各バッファは、ウィンドウに表示されることも されないこともあります。
Emacsの編集においてバッファとは、 異なる名前を持ち編集可能なテキストを保持するオブジェクトです。 バッファは、Lispプログラムには特別なデータ型として見えます。 バッファの内容は拡張可能な文字列であると考えることができます。 つまり、バッファのどの部分ででも挿入や削除を行えるのです。 See section 31. テキスト。
Lispのバッファオブジェクトには、さまざまな情報が含まれています。 変数を介してプログラマが直接参照できる情報もあれば、 特別目的の関数のみを介して参照できる情報もあります。 たとえば、訪問しているファイルの名前は、変数を介して直接参照できますが、 ポイントの値は基本関数を介してのみ参照できます。
直接参照可能なバッファに固有の情報は、
バッファローカル（buffer-local）な変数束縛、
つまり、特定のバッファでのみ有効な変数に保持されています。
この機能により、各バッファでは特定の変数の値を優先できます。
ほとんどのメジャーモードでは、このようにして、
fill-columnやcomment-columnなどの変数を優先させます。
バッファローカルな変数とそれらに関する関数について詳しくは、
10.10 バッファローカルな変数を参照してください。
バッファで訪問しているファイルに関する関数や変数については、 24.1 ファイルの訪問と24.2 バッファの保存を参照してください。 ウィンドウにバッファを表示することに関する関数や変数については、 27.6 バッファとウィンドウを参照してください。
tを返し、
さもなければnilを返す。
一般に、Emacsセッションには多くのバッファがあります。 いつの時点でも、それらの1つをカレントバッファ （current buffer）として区別します。 バッファ内のテキストを検査したり変更する基本関数は 暗黙のうちにカレントバッファに作用するため、 ほとんどの編集はカレントバッファに対して行われます （see section 31. テキスト）。 通常、スクリーン上で選択されたウィンドウに表示されているバッファが カレントバッファですが、つねにそうとは限りません。 Lispプログラムでは、スクリーン上の表示は変えずに、 任意のバッファの内容を操作するために 一時的に当該バッファをカレントバッファにできます。
Lispプログラムでカレントバッファを指定するには、
set-bufferを呼び出します。
新たに指定し直すまで指定したバッファがカレントバッファであり続けます。
編集コマンドがエディタコマンドループへ戻ると、
コマンドループは、混乱を避けるために、選択されているウィンドウに
表示されているバッファをカレントバッファとします。
つまり、Emacsがコマンドを読むときにカーソルがあるバッファが
コマンドが適用されるバッファです。
（See section 20. コマンドループ。）
したがって、set-bufferは、
ユーザーが編集できるように別のバッファへ切り替える方法にはなりません。
これには、27.7 ウィンドウへのバッファの表示で述べている関数を使う必要があります。
しかし、別のカレントバッファに替えるLisp関数では、
コマンドループがカレントバッファを
あとで戻すということに依存してはいけません。
Emacs Lispで書かれた編集コマンドは、コマンドループに加えて
別のプログラムからも呼ばれます。
サブルーティンがカレントバッファを替えないほうが
（それがサブルーティンの目的でなければ）、
呼び出し側にとっては便利です。
したがって、関数の実行が終るともとのカレントバッファに戻す
フォームsave-current-bufferや
save-excursion（see section 29.3 エクスカージョン）の内側で、
普通はset-bufferを使います。
例として、（説明文字列を簡略にして）コマンドappend-to-buffer
のコードを示します。
(defun append-to-buffer (buffer start end)
"Append to specified buffer the text of the region.
..."
(interactive "BAppend to buffer: \nr")
(let ((oldbuf (current-buffer)))
(save-current-buffer
(set-buffer (get-buffer-create buffer))
(insert-buffer-substring oldbuf start end))))
|
この関数では、ローカル変数を束縛してカレントバッファを記録し、
save-current-bufferでそれがカレントバッファに戻るようにしています。
つぎに、set-bufferで指定したバッファをカレントバッファにします。
最後に、insert-buffer-substringでもとのカレントバッファから
指定された（いまはカレント）バッファに文字列をコピーします。
内容を付加したバッファがどれかのウィンドウに表示されていると、 つぎに表示を更新したときに変更されたテキストが表示されます。 それ以外では、スクリーン上でただちには変更を見ることはできません。 コマンドの実行中にはバッファが一時的にカレントバッファになりますが、 それによりそのバッファが表示されるわけではありません。
バッファローカルな束縛を持つ変数を（letや関数の引数で）
ローカルに束縛する場合には、ローカルな束縛の有効範囲の開始時と終了時には、
同じバッファが必ずカレントバッファであるようにします。
さもないと、あるバッファでは変数を束縛し、
別のバッファではその束縛を解除してしまうことがあります。
これには2つの方法があります。
単純な場合には、束縛の有効範囲内で
カレントバッファが替わらないを確認します。
さもなければ、save-current-bufferやsave-excursionを使って、
始めにカレントバッファであったバッファが、
変数束縛が解除されるときにはつねにカレントバッファであるようにします。
set-bufferでもとのカレントバッファに戻すのでは信頼性がありません。
正しくないバッファがカレントバッファであるときに
中断が起きると戻せないからです。
してはいけないことをつぎに示します。
(let (buffer-read-only
(obuf (current-buffer)))
(set-buffer ...)
...
(set-buffer obuf))
|
つぎのようにsave-current-bufferを使えば、
通常の評価に加えて、中断、エラー、throwも扱えます。
(let (buffer-read-only)
(save-current-buffer
(set-buffer ...)
...))
|
(current-buffer)
=> #<buffer buffers.texi>
|
この関数はbuffer-or-nameで指定されるバッファを返す。 buffer-or-nameが既存のバッファを指定しなければ、エラーを通知する。
save-current-bufferは、
カレントバッファの識別子を保存し、フォームbodyを評価し、
最後にもとのカレントバッファに戻す。
戻り値は、bodyの最後のフォームの値である。
throwやエラー（see section 9.5 非ローカル脱出）による異常終了であっても
カレントバッファは戻される。
save-current-bufferから抜けるときに、
もとのカレントバッファとして使われていたバッファが削除されていると、
もちろん、カレントバッファにはならない。
そのかわりに、抜けるまえにカレントバッファであったバッファが
カレントバッファであり続ける。
with-current-bufferは、
カレントバッファの識別子を保存し、
bufferをカレントバッファにし、フォームbodyを評価し、
最後にもとのカレントバッファに戻す。
戻り値は、bodyの最後のフォームの値である。
throwやエラー（see section 9.5 非ローカル脱出）による異常終了であっても
カレントバッファは戻される。
with-temp-bufferは、
一時的なバッファをカレントバッファとして
フォームbodyを評価する。
カレントバッファの識別子を保存し、
一時的なバッファを作成してそれをカレントバッファにし、
フォームbodyを評価し、
最後にもとのカレントバッファに戻すとともに一時的なバッファを削除する。
戻り値は、bodyの最後のフォームの値である。
最後のフォームとして(buffer-string)を使えば、
一時的なバッファの内容を返せる。
throwやエラー（see section 9.5 非ローカル脱出）による異常終了であっても
カレントバッファは戻される。
24.4 ファイルへの書き出しのwith-temp-fileも参照してください。
各バッファには、文字列で一意な名前があります。 バッファに作用するほとんどの関数は、 引数としてバッファかバッファ名を受け付けます。 buffer-or-nameという名前の引数はこの種のものであり、 当該引数が文字列でもバッファでもないとエラーを通知します。 bufferという名前の引数は 実際のバッファオブジェクトである必要があり、名前ではだめです。
短命で一般にはユーザーが関心を示さないバッファの名前は空白で始まり、
コマンドlist-buffersやbuffer-menuはそれらを表示しません。
さらに、空白で始まる名前のバッファでは、
アンドゥ情報の記録も最初は禁止してあります。
31.9 アンドゥを参照してください。
buffer-nameがnilを返す場合、
bufferが削除されたことを意味する。
see section 26.10 バッファの削除。
(buffer-name)
=> "buffers.texi"
(setq foo (get-buffer "temp"))
=> #<buffer temp>
(kill-buffer foo)
=> nil
(buffer-name foo)
=> nil
foo
=> #<killed buffer>
|
通常、newnameがすでに使われていると、
rename-bufferはエラーを通知する。
しかし、uniqueがnil以外であると、
newnameを未使用な名前に修正する。
対話的に呼び出した場合、数値前置引数を指定すると
uniqueはnil以外になる。
このコマンドの1つの用途は、 バッファ`*shell*'を別の名前に改名して、 同じ`*shell*'という名前で別のシェルを作れるようにすることである。
nilを返す。
buffer-or-nameがバッファであればそれ自身を返す。
（これは有用ではないので、普通、引数は名前である。）
例を示す。
(setq b (get-buffer "lewis"))
=> #<buffer lewis>
(get-buffer b)
=> #<buffer lewis>
(get-buffer "Frazzle-nots")
=> nil
|
26.9 バッファの作成の関数get-buffer-createも参照。
26.9 バッファの作成の関連する関数generate-new-bufferを参照。
バッファファイル名（buffer file name）とは、
当該バッファで訪問しているファイルの名前です。
バッファでファイルを訪問していないときには、
バッファファイル名はnilです。
ほとんどの場面で、バッファ名は
バッファファイル名の非ディレクトリ部分と同じですが、
バッファファイル名とバッファ名は別のものであり個別に設定できます。
See section 24.1 ファイルの訪問。
buffer-file-nameはnilを返す。
bufferを指定しないと、
デフォルトはカレントバッファである。
(buffer-file-name (other-buffer))
=> "/usr/user/lewis/manual/files.texi"
|
nilである。
これは恒久的にバッファローカルであり、
kill-local-variablesに影響されない。
buffer-file-name
=> "/usr/user/lewis/manual/buffers.texi"
|
他のさまざまなことを行わずにこの変数の値だけを変更することは危険である。
通常、set-visited-file-name（下記参照）を使うほうがよい。
バッファ名を変更するなどの重要でないことも行うが、
Emacsを混乱させないように本質的なことも行うからである。
nilである。
これは恒久的にバッファローカルであり、
kill-local-variablesに影響されない。
see section 24.6.3 実名。
nilである。
これは恒久的にバッファローカルであり、
kill-local-variablesに影響されない。
この値は、通常、(filenum devnum)の形のリストである。
この数の対により、システム上のすべての参照可能なファイルを一意に識別できる。
これらについてより詳しくは、
24.6.4 ファイルに関する他の情報の関数file-attributesを参照。
nilを返す。
引数filenameは文字列であり、
展開（see section 24.8.4 ファイル名を展開する関数）してから
すべてのバッファの訪問しているファイル名と比較する。
(get-file-buffer "buffers.texi")
=> #<buffer buffers.texi>
|
稀れな状況では、複数のバッファが同じ名前のファイルを訪問している場合がある。 そのような場合、この関数はバッファリストで最初にみつかったバッファを返す。
filenameがnilだったり空文字列であると、
『ファイルを訪問していない』ことにする。
この場合、set-visited-file-nameは、
当該バッファではファイルを訪問していないと印を付ける。
通常、この関数は、指定したファイルが既存の場合には
ユーザーに確認をとる。
no-queryがnil以外であると、確認をとらない。
along-with-fileがnil以外であると、
それ以前に訪問していたファイルはfilenameと改名してあると仮定する。
関数set-visited-file-nameを対話的に呼び出すと、
ミニバッファでfilenameを問い合わせる。
Emacsは、各バッファごとに当該バッファのテキストを変更したかどうかを
記録する変更フラグ（modified flag）と呼ばれるフラグを保持しています。
バッファの内容が変わるたびにこのフラグはtに設定され、
保存するたびにnilに設定されます。
つまり、このフラグは未保存の変更があるかどうかを表します。
このフラグの値は通常モード行（see section 22.3.2 モード行に使われる変数）に表示され、
保存（see section 24.2 バッファの保存）と
自動保存（see section 25.2 自動保存）を制御します。
このフラグを明示的に設定するLispプログラムもあります。
たとえば、関数set-visited-file-nameはこのフラグをtに設定します。
ファイルを訪問してから変更していなくても、
バッファのテキストが新たな訪問しているファイルとは一致しないからです。
バッファの内容を変更する関数については31. テキストに述べてあります。
tを返し、
さもなければnilを返す。
bufferを指定しないとカレントバッファを調べる。
nil以外であれば
カレントバッファは変更されていると印を付け、
nilならば未変更であると印を付ける。
この関数を呼び出した別の効果として、
カレントバッファのモード行を無条件に再表示する。
実際、関数force-mode-line-updateはつぎのようにしている。
(set-buffer-modified-p (buffer-modified-p)) |
エコー領域にメッセージを表示するので、
プログラムからこの関数を使わないこと。
かわりにset-buffer-modified-pを使う（上記）。
nilであると（あるいは省略すると）、
カレントバッファを使う。
ファイルを訪問してそのバッファで変更したとします。 そのあいだに、ディスク上の当該ファイル自身も変更されたとします。 ここでバッファを保存すると、ファイルの変更内容を上書きしてしまいます。 たしかにこれを望む場合もあるでしょうが、 普通は重要な情報を失うことになります。 そのため、Emacsは、ファイルに保存するまえに、 以下に述べる関数を用いてファイルの更新時刻を検査します。
実際の更新時刻とEmacsに記録している更新時刻が同じならばtを返し、
さもなければnilを返す。
この関数は、set-visited-file-nameや
変更されたファイルを上書きしないためのテストを行わない例外的な場面で
呼び出される。
(high . low)の形のリストで返す。
（これはfile-attributesが時刻を返すために使う形と同じである。
24.6.4 ファイルに関する他の情報を参照。）
nil以外であるときには、
バッファに記録してあるファイルの最終更新時刻を
timeで指定された時刻にする。
さもなければ、訪問しているファイルの最終更新時刻にする。
timeがnilでないときには、
(high . low)か(high low)の形であること。
いずれの場合も、2つの整数は時刻の16ビットを保持する。
この関数は、ファイルから普通に読み込んだのではないバッファや ファイル自体が明確な理由で変更された場合に有用である。
ユーザーの応答に依存して、関数は正常に戻る。
その場合、バッファは変更できる。
あるいは、データ(filename)を付けて
エラーfile-supersessionを通知する。
その場合、バッファの変更は許されない。
この関数は、適切な場面でEmacsが自動的に呼び出す。 これを再定義することでEmacsをカスタマイズできるようにしている。 標準定義についてはファイル`userlock.el'を参照。
24.5 ファイルロックのファイルロック機構も参照。
バッファが読み出し専用（read-only）であると、 スクロールしたりナロイングしてその内容を眺めることはできますが、 その内容は変更できません。
読み出し専用バッファは、2種類の場面で使われます。
ここでの目的は、バッファを編集してファイルに保存しようとしても それに失敗するか望ましくないことであることをユーザーに伝えることである。 それにも関わらずバッファのテキストを変更したいユーザーは、 読み出し専用フラグをC-x C-qでクリアすれば編集できる。
これらのモードの特別なコマンドは、
それら自身がテキストを変更する場面では、
（letで）buffer-read-onlyにnilを束縛したり、
inhibit-read-onlyにtを束縛する。
nil以外であると、バッファは読み出し専用である。
nil以外であると、
読み出し専用バッファや読み出し専用文字を変更できる。
バッファ内の読み出し専用文字とは
（テキスト属性やオーバレイ属性の）
属性read-onlyがnil以外の文字である。
テキスト属性について詳しくは、see section 31.19.4 特別な意味を持つ属性。
重ね合わせとそれらの属性について詳しくは、see section 38.8 オーバレイ。
inhibit-read-onlyがtであると、
すべての文字の属性read-onlyは効果を失う。
inhibit-read-onlyがリストであると、
文字の属性read-onlyが（eqで比較して）
リストのメンバであると効果を失う。
buffer-read-onlyを
tかnilの正しい値に明示的に設定できる。
buffer-read-onlyを通知する。
カレントバッファが読み出し専用であるときに
エラーを通知する別の方法については、see section 20.3 対話的呼び出し。
バッファリスト（buffer list）は、
すべてのバッファのリストです。
バッファを作成すると当該バッファはこのリストに追加され、
削除するとこのリストから取り除かれます。
リスト内のバッファの順序は、各バッファが選択されているウィンドウに
どの程度最近に表示されたかを主な基準にしています。
バッファが選択されるとリストの先頭に移動し、
隠されると（下記のbury-bufferを参照）末尾に移動します。
other-bufferをはじめとするいくつかの関数が、この順序を使います。
ユーザーに表示するバッファ一覧もこの順序を反映しています。
Emacs基本バッファリストに加えて、
各フレームには独自のバッファリストがあります。
そのリストでは、
当該フレームでもっとも最近に選択されたバッファから順に
当該フレームで選択されたバッファが先にきます。
（この順番は、フレームのフレームパラメータbuffer-listに入っている。
28.3.3 ウィンドウフレームのパラメータを参照。）
当該フレームで選択されたことがないバッファは、
Emacs基本バッファリストでの順にうしろに続きます。
frameがフレームであると、
この関数はフレームframeのバッファリストを返す。
frameがnilであるとEmacs基本バッファリストを使う。
(buffer-list)
=> (#<buffer buffers.texi>
#<buffer *Minibuf-1*> #<buffer buffer.c>
#<buffer *Help*> #<buffer TAGS>)
;; ミニバッファの名前は空白で始まることに注意
(mapcar (function buffer-name) (buffer-list))
=> ("buffers.texi" " *Minibuf-1*"
"buffer.c" "*Help*" "TAGS")
|
buffer-listが返すリストはbuffer-listが構築したものであり、
Emacsの内部データ構造ではなく、
それを変更してもバッファの順序には影響しません。
フレーム独立なバッファリスト内のバッファ順序を変更するには、
つぎのような簡単な方法があります。
(defun reorder-buffer-list (new-list)
(while new-list
(bury-buffer (car new-list))
(setq new-list (cdr new-list))))
|
この方法を使えば、どんな順序でもリストに指定でき、 しかも、バッファを失ったり正しくないバッファを 追加してしまう危険はありません。
フレームのバッファリストの順序や値を変更するには、
modify-frame-parameters（see section 28.3.1 フレームパラメータの参照）で、
フレームのフレームパラメータbuffer-listに設定します。
bufferを指定しないと（あるいはバッファでないと）、
other-bufferは、選択されているフレームのバッファリストの中から
可視フレームのどのウィンドウにも表示されていない最初のバッファを返す。
frameにnil以外のパラメータbuffer-predicateがあると、
other-bufferは当該述語を使って
どのバッファを考慮に入れるかを決定する。
各バッファについて当該述語を1回呼び出し、
その値がnilであると当該バッファを無視する。
see section 28.3.3 ウィンドウフレームのパラメータ。
visible-okがnilであると、
other-bufferは可視フレームのいずれかのウィンドウに
表示されているバッファを可能な限り返さないようにする。
visible-okがnil以外であると、
バッファが表示されているかどうかは関係ない。
適当なバッファが存在しない場合には、 バッファ`*scratch*'を（必要ならば作成して）返す。
other-bufferが返す候補としては
もっとも可能性が低くなる。
bury-bufferは、
Emacsのフレーム独立なバッファリストに加えて、
各フレームのパラメータbuffer-listも操作する。
したがって、指定したバッファは、
(buffer-list frame)と(buffer-list nil)の
いずれの値でも最後になる。
buffer-or-nameがnilであるか省略すると、
カレントバッファを最後尾に置くことを意味する。
さらに、当該バッファが選択されているウィンドウに表示されていると、
そのウィンドウでは（other-bufferで得られる）
別のバッファに切り替わる。
当該バッファが別のウィンドウにも表示されている場合、
その表示は替わらない。
すべてのウィンドウに表示している特定のバッファを置き換えるには、
replace-buffer-in-windowsを使う。
see section 27.6 バッファとウィンドウ。
本節では、バッファを作成するための2つの基本関数を説明します。
get-buffer-createは、指定した名前のバッファが
存在しなければバッファを作成します。
generate-new-bufferは、つねに新たなバッファを作成し、
それに一意な名前を与えます。
バッファを作成するために読者が使える他の関数には、
with-output-to-temp-buffer（see section 38.7 一時的な表示）、
create-file-buffer（see section 24.1 ファイルの訪問）があります。
サブプロセスを開始してもバッファを作ります（see section 36. プロセス）。
nameが文字列でないとエラーを通知する。
(get-buffer-create "foo")
=> #<buffer foo>
|
新たなバッファのメジャーモードは基本（fundamental）モードに設定される。
変数default-major-modeは、より高いレベルで処理される。
see section 22.1.3 メジャーモードの選択方法。
nameが文字列でないとエラーを通知する。
(generate-new-buffer "bar")
=> #<buffer bar>
(generate-new-buffer "bar")
=> #<buffer bar<2>>
(generate-new-buffer "bar")
=> #<buffer bar<3>>
|
新たなバッファのメジャーモードは基本（fundamental）モードに設定される。
変数default-major-modeは、より高いレベルで処理される。
see section 22.1.3 メジャーモードの選択方法。
26.3 バッファ名の関連する関数generate-new-buffer-nameを参照。
バッファを削除するとは、Emacsに当該バッファの名前を忘れさせ、 それが使っていた場所を他の目的に使えるようにすることです。
削除されたバッファを表すバッファオブジェクトは、
それを指すものが存在する限り存在し続けますが、
それをカレントバッファにしたり表示できないように特別な印が付いています。
削除されたバッファの識別子は残っているので、
異なる2つのバッファを削除しても、
eqに関する限りそれらは区別できるのです。
カレントバッファやウィンドウに表示しているバッファを削除すると、 そのかわりにEmacsは別のバッファを選択したり表示します。 つまり、バッファを削除すると一般にはカレントバッファが 替わりうることを意味します。 したがって、バッファを削除するときには、 （削除するバッファがカレントバッファではないことがわかっていない限り） カレントバッファを替える可能性についてあらかじめ注意しておく必要があります。 See section 26.2 カレントバッファ。
複数の間接バッファの基底バッファであるバッファを削除すると、 間接バッファも自動的に削除されます。
削除されたバッファのbuffer-nameはnilです。
これを使えばバッファが削除されているかどうか調べられます。
(defun buffer-killed-p (buffer) "Return t if BUFFER is killed." (not (buffer-name buffer))) |
nilを返す。
当該バッファをprocess-bufferとしているすべてのプロセスに
シグナルSIGHUPを送る。
このシグナルは、通常、プロセスを終了させる。
（SIGHUPの基本的な意味は、接続回線が切断されたである。）
see section 36.5 プロセスの削除。
当該バッファがファイルを訪問していて、かつ、未保存の変更があれば、
kill-bufferは当該バッファを削除するまえにユーザーに確認をとる。
確認をとらないようにするには、kill-bufferを呼び出すまえに
バッファの変更フラグをクリアしておく。
see section 26.5 バッファの変更。
削除済みのバッファを削除してもなんの効果もない。
(kill-buffer "foo.unchanged")
=> nil
(kill-buffer "foo.changed")
---------- Buffer: Minibuffer ----------
Buffer foo.changed modified; kill anyway? (yes or no) yes
---------- Buffer: Minibuffer ----------
=> nil
|
kill-bufferは、
リストkill-buffer-query-functionsの関数を現れる順に
引数なしで呼び出す。
これらの関数が呼び出されるときには、
削除対象のバッファがカレントバッファである。
これらの関数でさまざまな非標準的な理由から
ユーザーの確認をとることが目的である。
いずれかがnilを返すと、kill-bufferはバッファを削除しない。
kill-bufferが問い合わせをすべて完了し
バッファを実際に削除する直前に実行されるノーマルフックである。
フック関数を実行するときには、削除対象のバッファがカレントバッファである。
see section 22.6 フック。
nil以外であると、
save-buffers-kill-emacsとsave-some-buffersに対して
ファイルを訪問しているバッファと同様に
当該バッファを保存する機会を与えるように指示する。
変数buffer-offer-saveに
設定すると自動的にバッファローカルになる。
間接バッファ（indirect buffer）は、 間接バッファの基底バッファ（base buffer）と呼ばれる 他のバッファのテキストを共有します。 ある意味で、バッファにおいて ファイルのシンボリックリンクに相当するものです。 基底バッファそのものは間接バッファであってはなりません。
間接バッファのテキストは、その基底バッファのテキストとつねに同一です。 どれかを編集して変更すると、別のものでただちに見えます。 これには、文字そのものに加えてテキスト属性も含みます。
しかし、それ以外に関しては、間接バッファと その基底バッファは完全に別のものです。 別の名前を持ち、ポイントの値も別であり、異なったナロイングをでき、 （いずれかのバッファでテキストを挿入したり削除すると マーカと重ね合わせは再配置されるが）マーカやオーバレイも異なり、 異なるメジャーモードを持ち、バッファローカルな変数も異なります。
間接バッファはファイルを訪問できませんが、その基底バッファでは訪問できます。 間接バッファを保存しようとすると、実際にはその基底バッファを保存します。
間接バッファを削除しても、その基底バッファには影響ありません。 基底バッファを削除すると、その間接バッファを実質的には削除することになり、 間接バッファをカレントバッファにはけっしてできなくなります。
nilである。
さもなければ、値は間接バッファではない別のバッファである。
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |