検索エンジンから来た人に注意このマニュアルは、Emacs ver. 19.x 向けのマニュアルを Mule 2.x の開発にあたり邦訳したものを、 電脳外道学会がミラーリングしているものであり、旧版製品パラノイアであるところの椅子人の趣味によるものです。しかしながら、現在の Emacs の主流は ver. 20 以降であり、ver 19.x と ver 20.x とでは、仕様の違いが少なからずあります。 したがって、一般的な Emacs ユーザーにとっては、
このマニュアルと実機の動作とが符合しない場合があります。
|
バッファ(buffer)は、編集するテキストを格納するLispオブジェクトで す。通常、バッファは対応づけられたファイルの内容を保持するのに用いられま すが、ファイルに対応づけられていないバッファもあります。同時に複数のバッ ファが存在することができますが、常にただ一つのバッファがカレント・ バッファ(current buffer)となります。ほとんどの編集命令はカレント・バッ ファの内容に対して行なわれます。カレント・バッファを含め、バッファはウィ ンドウに表示されるかもしれませんし、されないかもしれません。
Emacsにおいて編集対象としているバッファは、明確な名前を持った、編集 可能なテキストを保持するオブジェクトです。バッファはLispプログラムの 中では一つの特殊なデータ型です。バッファの内容は拡張可能な文字列と考える ことができます。バッファの任意の部分のの追加および削除が行なわれます。 See section テキスト。
個々のLispバッファ・オブジェクトは多くの情報を持ちます。この情報の いくつかは変数としてプログラマから直接アクセスされ、その他の情報は特別 な関数によってのみアクセスされます。たとえば、対応づけられたファイル名は 変数によって直接アクセスできますが、ポイントの値はプリミティブ関数によっ てのみアクセスできます。
直接アクセスできるバッファ固有の情報は、その値がある特定のバッファで
のみ有効である、バッファローカル(buffer-local)変数に格納されま
す。この特徴により、それぞれのバッファで変数の値を上書きすることが可能
となります。ほとんどの主モードは、この手段を用いてfill-column
やcomment-column
などのような変数を上書きしています。バッファ
ローカル変数とその関連関数の詳細についてはsection バッファローカルな変数
を参照してください。
バッファに対応づけられるファイルに関する関数や変数については、 section ファイルをvisitするとsection バッファを保存するを参照してください。ウィン ドウ内のバッファの表示に関する関数や変数については、section バッファとウィンドウを参照してください。
t
を返し、そうでな
ければnil
を返します。
一般に一回のEmacsセッションの間に多くのバッファが用いられます。常に その中の一つがカレント・バッファ(current buffer)となります。バッ ファ内のテキストを調べたり変更するプリミティブのほとんどが、暗黙に (implicitに)カレント・バッファに対して処理を行うため、このカレント・ バッファ内でほとんどの編集が行なわれます(see section テキスト)。通常は、選択され たウィンドウ内のスクリーンに表示されたバッファがカレント・バッファです が、そうでない場合もあります。Lispプログラムは、あるバッファの内容に 対する処理を行うために、スクリーンに表示されているものを変更することな く、そのバッファを一時的にカレント・バッファとすることができます。
Lispプログラムでは、set-buffer
を呼ぶことによりカレント・バッファ
を選択します。選択されたバッファは、新たなバッファが選択されるまでカレン
トのままでいます。
編集命令が編集コマンド・ループ(editor command loop)に戻るとき、混乱を
避けるために、コマンド・ループは選択されたウィンドウに表示されているバッ
ファをカレント・バッファにします。つまりEmacsが命令を読み込んだときにカー
ソルがあったバッファがその命令の適用されるバッファとなります
(See section コマンド・ループ)。したがってset-buffer
は、ユーザが他のバッファ
を編集する目的でバッファを変更するための手段ではありません。この目的のた
めにはsection ウィンドウ内でのバッファの表示に説明されている関数を使わねばなりません。
しかし、カレント・バッファを変更するLisp関数は、それを元に戻す作業をコ
マンド・ループに頼るべきではありません。Emacs Lispで書かれた編集命令は、
コマンド・ループからのほかに、他のプログラムからも呼ばれます。呼ぶ側にとっ
ては、サブルーチンがカレント・バッファを変更しない方が便利です(もちろん、
それが目的である関数は別です)。したがって通常は、終了したときにカレント・
バッファを元に戻す関数であるsave-excursion
の中でset-buffer
を使用すべきです(see section 脱線)。例として、命令
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-excursion (set-buffer (get-buffer-create buffer)) (insert-buffer-substring oldbuf start end))))
この関数は、ローカル変数をカレント・バッファに束縛し、
save-excursion
がポイント、マーク、もとのバッファをそれぞれ記録し
ます。次にset-buffer
が別のバッファをカレント・バッファにします。
最後に、insert-buffer-substring
が、もとのカレント・バッファから新た
なカレント・バッファへ文字列をコピーします。
文字列が追加されたバッファがウィンドウ内に表示されている場合は、次 の画面の書き換えを行うときにテキストの変更が表示されるようになります。表 示されていない場合は、画面からはすぐには変更を見ることができません。つま りそのバッファは、コマンドの実行中は一時的にカレントになりますが、表示さ れるわけではありません。
バッファローカルである変数を(let
もしくは関数の引数によっ
て)ローカル束縛するときは、ローカル束縛するスコープの最初と最後で、同じ
バッファがカレントであるようにしてください。そうしなければ、その変数をあ
るバッファで束縛した後、別のバッファ内で束縛をとく(unbind)ことになります。
変数のスコープの最初と最後とで同じバッファをカレントであるようにするのに、
2とおりの方法があります。簡単なものは、その束縛のスコープ中でカレント・
バッファを変更しないことです。もう一つは、変数の束縛をとくときに、最初に
カレントであったバッファを再度カレントにすることを保証する
save-excursion
を用いることです。
set-buffer
を用いてカレント・バッファを戻すのは危険です。戻りた
いバッファではないバッファがカレントである状態でとりやめ(quit)が起きたと
きに、set-buffer
が呼ばれないからです。次の例はやってはいけ
ない例です。
(let (buffer-read-only (obuf (current-buffer))) (set-buffer ...) ... (set-buffer obuf))
次に示すようにsave-excursion
を用いると、通常の動作はもとより、と
りやめ(quit)、エラー、throw
も正しくハンドルされます。
(let (buffer-read-only) (save-excursion (set-buffer ...) ...))
(current-buffer) => #<buffer buffers.texi>
この関数はbuffer-or-nameで識別されるバッファを返します。 buffer-or-nameによって既存のバッファのうちの一つを特定できない場 合はエラーとなります。
個々のバッファは一意な名前を文字列として持ちます。バッファに対して処理 を行う多くの関数は、バッファもしくはバッファの名前を引数として受けつけま す。buffer-or-nameと呼ばれる引数がこの種のもので、もし文字列もしく はバッファのいずれでもない場合はエラーとなります。bufferと呼ばれる 引数は、名前ではなくバッファ・オブジェクトでなければなりません。
短期的に用いられ、通常はユーザが興味を持たないようなバッファは空白文字
で始まる名前を持ちます。こうすることによって、list-buffers
命令と
buffer-menu
命令の対象とはならなくなります。さらに、空白文字で始ま
る名前のバッファは、最初にundo情報の記録が禁止されます。section 取り消しを参照
してください。
buffer-name
がnil
を返した場合は、bufferが
すでにkillされていることを意味します。See section バッファの消去。
(buffer-name) => "buffers.texi" (setq foo (get-buffer "temp")) => #<buffer temp> (kill-buffer foo) => nil (buffer-name foo) => nil foo => #<killed buffer>
newname
を返します。
通常、newnameがすでに使われている場合は、rename-buffer
はエ
ラーとなります。しかしuniqueがnil
でない場合は、関数
generate-new-buffer
を用いて、newnameを使われていない名前に
変更します。対話的に用いる場合は、数値前置引数によってuniqueを
nil
でない値とします。
この命令の使い方の一つとして、`*shell*'バッファを別の名前にするとい うものがあります。こうすることにより`*shell*'という名前の第2のシェ ル・バッファを作ることが可能となります。(18)
nil
となります。buffer-or-nameがバッファの場
合は、それをそのまま返します(これはあまり役に立たないため、通常は名
前が引数となります)。たとえば
(setq b (get-buffer "lewis")) => #<buffer lewis> (get-buffer b) => #<buffer lewis> (get-buffer "Frazzle-nots") => nil
section バッファの生成の関数get-buffer-create
も参照してくださ
い。
section バッファの生成の関連する関数generate-new-buffer
を参照
してください。
バッファ・ファイル名(buffer file name)は、バッファに対応づけられたファイルの名前で
す。バッファがファイルに対応づけられていない場合は、そのバッファ・ファイ
ル名はnil
となります。ほとんどの場合、バッファ名は、バッファ・ファ
イル名のディレクトリ部分を取り除いたものと同じですが、バッファ・ファイル
名とバッファ名は区別され、独立に設定することができます。See section ファイルをvisitする。
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"
ほかのいろいろな手続きを踏まずにこの変数の値を変更することは危険です。
`files.el'のset-visited-file-name
の定義を参考にしてくださ
い。バッファ名の変更など、そこで行なわれていることのいくつかは厳密には必
要ではありませんが、そのほかはEmacsを混乱させないために必要なことです。
nil
を持ちます。常にローカル変数であり
kill-local-variables
の影響を受けません。See section 実名。
nil
を持ちます。常時ローカル変数であり
kill-local-variables
の影響を受けません。See section 実名。
この変数の値は通常(filenum devnum)
の形式のリストで
す。この数字の組によって、システムでアクセス可能な全てのファイル中から
そのファイルを一意に特定することができます。これらのより詳しい情報は、
section ファイルに関するそのほかの情報の関数file-attributes
を参照ください。
nil
を返します。引数filename
(文字列でなければなりません)は展開されたあと(see section ファイル名を展開する関数)全てのバッファに対応づけられたファイル名と比較されます。
(get-file-buffer "buffers.texi") => #<buffer buffers.texi>
特殊な状況では、同じファイル名に複数のバッファが対応づけられていること がありえます。このような場合、この関数はバッファ・リストの中の最初のも のを返します。
filenameがnil
もしくは空文字列である場合は、"対応づけられた
ファイルがない" ことを表わします。この場合は
set-visited-file-name
はバッファに対応するファイルがないと印をつけ
ます。
set-visited-file-name
が対話的に呼ばれた場合はミニバッファで
filenameの入力を促します。
section バッファの変更の中のclear-visited-file-modtime
と
verify-visited-file-modtime
を参照してください。
Emacsは、それぞれのバッファごとにそのバッファのテキストを変更したか否か
を記録するために、変更フラグ(modified flag)と呼ばれるフラグを管理します。この
フラグはバッファの内容を変更したときにt
となり、バッファを保存
(保存)したときにnil
となります。したがってこのフラグは、保存
されていない変更があるか否かを示します。このフラグの値は通常モード・ラ
インに表示され(see section モード行の中で使用されている変数)、ファイルの保存や
(see section バッファを保存する)自動保存(auto-saving)の(see section 自動セーブ)
制御をします。
いくつかのlispプログラムはこのフラグを明示的に設定します。たとえば
関数set-visited-file-name
は、フラグをt
とします。これ
はテキストが以前対応づけられていたファイルから変更されてはいませんが、新
たに対応づけられたファイルとは一致していないためです。
バッファの内容を変更する関数についてはsection テキストに記述されています。
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
が時間の値を返すのに用いる形式と同じものです。
section ファイルに関するそのほかの情報を参照してください)。
nil
でない場合はtimeで指定された値に、nil
の場合は対
応づけられたファイルの最終変更時間に、それぞれ書き換えます。
timeがnil
でないときは、それは(high
. low)
もしくは(high low)
の形式でなければな
りません。いずれの場合も二つの整数値を持ち、それぞれが時間の16ビット
分の値を保持します。
この関数は、バッファが普通にファイルから読まれなかった場合や、ファイル 自身がある正常な理由で変更された場合などに便利です。
この関数は、ユーザの答えによって、正常に終了し、バッファはそのまま変更さ
れるか、データ(filename)
を伴ってfile-supersession
エ
ラーが通知され、バッファの変更はされないかの、いずれかとなります。
この関数は、Emacsによって適切なときに自動的に呼ばれます。この関数を再定 義することによってEmacsをカスタマイズすることができるように用意されてい ます。標準的な定義としてはファイル`userlock.el'を参照してください。
section ファイルのロックのファイル・ロック機構も参照してください。
バッファが読みだし専用(read-only)である場合は、その内容を変更 することはできませんが、スクロールしたりナローイングを行うことによって、 その見え方を変更することは可能です。
読みだし専用バッファは2種類の状況で用いられます。
buffer-read-only
を(let
を用いて) nil
とするか、
inhibit-read-only
をt
とします。
nil
でないときはそのバッファは読みだし専用です。
nil
でないときは、読みだし専用バッファや読みだし専用文字
も変更することが可能です。読みだし専用文字とは、nil
でない読
みだし専用
属性(テキスト属性とオーバレイ属性のいずれか)をもつ文字です。
テキスト特性についての詳細はSee section 特殊な意味をもつ属性。オーバレイやその
属性についての詳細はSee section オーバレイ。
inhibit-read-only
がt
の場合は、全ての読みだし専
用
文字属性は効果がありません。inhibit-read-only
がリストの場合
は、読みだし専用
文字属性がリストのメンバである場合に(eq
で比較が行なわれます)その効果がなくなります。
buffer-read-only
をt
かnil
の適切な値に設定することができます。
buffer-read-only
エラーを通知します。カレント・バッファが読みだし
専用であるときにエラーを通知するもう一つの方法として、See section 対話的呼出し。
バッファ・リスト(buffer list)は、全ての使用可能なバッファのリス
トです。バッファを生成するとこのリストに加えられ、バッファをkillするとこ
のリストから削除されます。リスト内のバッファの順序は、基本的には選択され
ているウィンドウに最近表示されたものほど先頭に近くなっています。バッファ
は、選択されるとこのリストの先頭に移動し、関数bury-buffer
によって
リストの末尾に移動します。いくつかの関数、特にother-buffer
は、こ
の順序を使用します。ユーザに表示されるバッファのリストもこの順序となりま
す。
(buffer-list) => (#<buffer buffers.texi> #<buffer *Minibuf-1*> #<buffer buffer.c> #<buffer *Help*> #<buffer TAGS>) ;; minibufferの名前がスペースで始まることに注意! (mapcar (function buffer-name) (buffer-list)) => ("buffers.texi" " *Minibuf-1*" "buffer.c" "*Help*" "TAGS")
このリストは、Emacs内部で使われているリストのコピーです。これを変更して もバッファの順序には影響を与えません。
bufferが省略された場合は(もしくはそれがバッファではなかったら)、
other-buffer
は、現在表示されているフレーム内のどのウィンドウにも
表示されていない、バッファ・リスト内で最初のバッファを返します。
選択されたフレームがnil
以外のbuffer-predicate
パラメータを
持っている場合は、関数other-buffer
は、この述語(predicate)を用いて
バッファを選択します。それぞれのバッファごとにこの述語を呼び、その値が
nil
であればそのバッファは無視されます。See section Xウインドウ・フレーム・パラメータ。
visible-okがnil
であれば、ほかにバッファがあるかぎり、
other-buffer
は現在表示されているフレーム内の全てのウィンドウに表
示されているものを除外します。visible-okがnil
でなければ、
バッファが表示されているか否かは関係なくなります。
適切なバッファがない場合は、バッファ`*scratch*'が(必要であれば 生成され)返されます。
other-buffer
が返すバッファとして最も優先度の低いものになります。
buffer-or-nameがnil
もしくは省略された場合は、カレント・バッ
ファが対象となります。さらに、カレント・バッファが選択されたウィンドウに
表示されている場合は、選択されたウィンドウの(other-buffer
によって
選択される)他のバッファが表示されます。しかし他のウィンドウに表示されて
いる場合は、そこに表示されたままとなります。
全てのウィンドウ内に表示されているあるバッファを置き換えたい場合は、
replace-buffer-in-windows
を使用してください。See section バッファとウィンドウ。
この節ではバッファを生成する2種類のプリミティブについて説明します。
get-buffer-create
は指定された名前のバッファが存在してない場合に
バッファを生成します。generate-new-buffer
は常に新しいバッファを
生成し、それにユニークな名前を与えます。
バッファを生成する関数として、ほかにwith-output-to-temp-buffer
(see section 一時表示)とcreate-file-buffer
(see section ファイルをvisitする)とがあります。またサブプロセスの起動によっても
バッファを生成することができます。
nameが文字列でない場合は、エラーが通知されます。
(get-buffer-create "foo") => #<buffer foo>
新たなバッファの主モードはFundamentalモードとなります。変数
default-major-mode
はもっと上位の階層で処理されます。
See section 主モードの自動選択の仕組み。
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 主モードの自動選択の仕組み。
関連する関数としてsection バッファの名前のgenerate-new-buffer-name
を参照してください。
バッファの消去(killing a buffer)によって、Emacsからその名前が忘れ去られ、その テキスト空間がほかの目的に使用できるようになります。
消去されたバッファのバッファ・オブジェクトは、それが参照される間は存
在し続けますが、それをカレント・バッファにしたり表示したりはできないよ
うに特別な印がつけられます。しかし消去されたバッファもその独自性は持ち
続けます。よって二つのバッファが消去されたとしてもeq
によって
区別することができます。
消去されたバッファがカレント・バッファであったりウィンドウに表示されて いた場合は、Emacsは自動的に他のバッファを選択あるいは表示します。これは バッファの消去が一般にカレント・バッファを変更することを意味します。した がって、バッファを消去するときは(消去するバッファがカレント・バッファで ないことが分かっているのでないかぎり)、カレント・バッファが変更される場 合にしなければならない予防措置を取らなければなりません。See section カレント・バッファ。
一つもしくは複数の間接バッファの元バッファ(base buffer)を消去する場合 は、その間接バッファも全て自動的に消去されます。
消去されたバッファの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 プロセスの削除。
バッファが、あるファイルに対応づけられていて、保存されていない変更がある
場合は、kill-buffer
はバッファが消去されるまえにユーザに確認を行な
います。この確認は対話的に呼ばれなかったときにも行なわれます。確認の要求
が起きないようにするためは、kill-buffer
を呼ぶ前に、変更フラグを解
除してください。See section バッファの変更。
すでに消去されているバッファを消去しても無視されるだけです。
(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 フック。
nil
でない場合は、
save-buffers-kill-emacs
とsave-some-buffers
は、通常ファ
イルに対応づけられたバッファを保存しようとするのと同じように、そのバッ
ファを保存します。変数buffer-offer-save
は、何らかの理由で設定
されたときに自動的にバッファローカルとなります。See section バッファローカルな変数。
間接バッファ(indirect buffer)は、間接バッファの元バッファ (base buffer)と呼ばれる他のバッファのテキストを共有します。いくつかの 点でファイルでのシンボリック・リンクに類似します。元バッファ自身がその 間接バッファであってはなりません。
間接バッファのテキストは、常に元バッファのものと同一です。いずれかを 編集することによる変化は、直ちにもう一方でも表示されます。文字と同様に テキスト属性も含みます。
しかし、他の全ての点で間接バッファとその元バッファとは完全に別のものです。 名前も、ポイントの値も、ナローイングも、マーカやオーバレイも(ただし、い ずれかのバッファでのテキストの追加や削除は、両方のバッファのマーカとオー バレイを更新しますが)、主モードも、ローカル変数も、全て異なります。
主バッファはファイルに対応づけられますが、間接バッファはファイルに対 応づけられません。間接バッファを保存しようとすると、実際には主バッ ファが保存されます。
間接バッファを消去しても、主バッファにはなんの影響もありません。主バッ ファの消去は実質的にその間接バッファを消去するため、その間接バッファが 2度とカレント・バッファとなることはありません。
base-bufferが間接バッファである場合は、その主バッファが新たなバッ ファの主バッファになります。
nil
となります。間接バッファである場合の値は、間
接バッファではない他のバッファとなります。
Go to the first, previous, next, last section, table of contents.