意図してないEmacsコマンドを打つと、 その結果はわけのわからないものになりがちです。 本章では、まちがいを取り消したり、 わけのわからない状況から復帰する手段について説明します。 また、Emacsのバグやシステムクラッシュについても説明します。
abort-recursive-edit
)。
keyboard-escape-quit
)。
undo
)。
実行を完了していないコマンドを取り消すには、2つの方法があります。 1つはC-gで中断すること、 もう1つはC-]やM-x top-levelで アボートすることです。 中断とは、打鍵途中のコマンドや動作中のコマンドを取り消すことをいいます。 アボートとは、再帰編集レベルから抜け出し、かつ、 その再帰編集レベルを起動したコマンドを取り消すことをいいます (see section 再帰編集レベル)。
C-gでの中断は、打鍵途中のコマンドや 不要な数引数を打ってしまったときにとりやめるのに使います。 また、実行途中のコマンドを比較的安全な方法で止めますから、 長時間かかるコマンドをうっかり始めてしまったときにも使えます。 特に、キル操作を中断しても安全です。 テキストは、まだすべてバッファ内にあるか、 または、すべてキルリングに入っている (あるいは、その両方に入っている)からです。 なお、インクリメンタルサーチを中断する場合には、 文字列探索のところで説明してあるように、特別な動作を行います。 一般には、サーチから抜け出すにはC-gを2回連打する必要があります (see section インクリメンタルサーチ)。
MS-DOSでは、C-BREAKはC-gと同様に中断として働きます。 MS-DOSでは、コマンドの実行中にユーザーとのやりとりを行う状態にないときには、 C-gを検出できないからです。 これに対して、C-BREAKはつねに認識できます。 See section MS-DOSのキーボードとマウス。
C-gはつぎのように動作します。
C-gが打鍵されると変数quit-flag
にt
が設定されます。
Emacs Lispはこの変数を頻繁に調べ、値がnil
以外だと中断処理を行います。
C-gが実際にコマンドとして実行されるのは、
Emacsが入力待ち状態にあるときにC-gを打った場合だけです。
最初のC-gが認識されないうちに2つめのC-gを打って中断すると、 『緊急脱出』機能を発動したことになりシェルに戻ります。 See section 緊急脱出。
中断できない場合もありえます。 Emacsがオペレーティングシステムに何かを頼んで待っているときには、 待ち状態を起こしたシステムコールを使ったEmacs側で特別な手当てをしない限り 中断できません。 Emacsでは、ユーザーが中断しそうなシステムコールには 手当てを施してありますが、手当てしていない場所を叩く可能性はあります。 よくあるのは、NFS経由の入出力を待っているときです。 Emacs側ではこれを中断する方法はわかっているのですが、 多くのNFSの実装では、NFSサーバーが固まったときにユーザープログラムが NFSの待ちを中断することを許していないのです。
C-]によるアボート(abort-recursive-edit
)は、
再帰編集レベルから脱出し、かつ、その再帰編集レベルを
起動したコマンドを取り消すのに使います。
C-gによる中断はこのような目的には使えませんし、
このようなことはできません。
というのは、C-gは、ある再帰編集レベルの中で
打ちかけたコマンドを取り消すのに使うからです。
どちらの操作も必要なものです。
たとえば、再帰編集中に数引数を入力しようとしてC-u 8と打鍵した場合、
C-gで数引数を取り消しても再帰編集に留まったままです。
コマンドESC ESC ESC
(keyboard-escape-quit
)は、中断かアボートのいずれかを行います。
このキーを使うのは、多くのPCのソフトでESCが
『抜け出す』の意味に使われているからです。
C-gと同様に、数引数を取り消したり、
選択したリージョンをクリアしたり、問い合わせ型置換操作から抜け出します。
C-]と同様に、ミニバッファや再帰編集から抜け出します。
また、C-x 1のように、フレームを複数ウィンドウに分割しているのを
やめることもできます。
しかしながら、実行中のコマンドを止めることはできません。
なぜなら、このコマンドは普通のコマンドとして実行されるので、
Emacsがコマンドを読み込む状態にならないとこのコマンドを認識しないからです。
コマンドM-x top-levelは、現在入っているすべての再帰編集レベルから 抜け出すのに『十分な』数のC-]と同等です。 C-]は一度に1レベルだけ抜け出すのに対し、 M-x top-levelはすべてのレベルを一気に抜け出します。 C-]もM-x top-levelも他のコマンドと同様の普通のコマンドですから、 C-gとは違って、Emacsがコマンドを受け付ける状態のときだけ動作します。 C-]は普通のキーであり、キーマップにそのバインディングがあるので そのように動作するのです。 See section 再帰編集レベル。
C-x u(undo
)は、正確にいえばコマンドを
取り消すわけではありませんが、
動作を完了してしまったコマンドを取り消すものと考えることができます。
See section 変更をアンドゥする(もとに戻す)。
本節では、Emacsが正常に動作し損なうさまざまな条件と、それらの見分け方、 直し方について説明します。
DELが文字を削除するかわりにControl-hのように ヘルプに入ってしまう場合には、 使っている端末がDELに対してまちがった文字コードを送出しています。 この問題に対処するには、キーボード変換表を変更します (see section キーボード変換)。
再帰編集レベルはEmacsの重要で有用な機能ですが、 それについて理解していない人にとっては、誤動作に見える可能性があります。
モード行のメジャー/マイナモード名を囲む丸括弧の周囲に中括弧 `[...]'が表示されているときは、再帰編集レベルに入っています。 意図してそうしたのでなかったり、 再帰編集レベルの意味を理解していないのであれば、 再帰編集レベルから抜け出すべきです。 それにはM-x top-levelと打ちます。 これをトップレベルへの抜け出しと呼びます。 See section 再帰編集レベル。
画面上のデータがまちがっているように見えたら、まず最初にすべきことは、 テキストが本当にまちがっているのかどうか調べることです。 C-lと打って画面全体を再描画します。 これで画面が正しそうになるのなら、問題は画面更新にあったのです。 (そうでない場合は、see section テキスト内のゴミ)。
画面更新の問題は、 使っている端末に対応するtermcapの定義がまちがっている場合が多いです。 Emacsの配布に含まれるファイル`etc/TERMS'には、 この種の問題で既知のものに対する修正が入っています。 ファイル`INSTALL'には、 この種の問題に対する一般的なアドバイスの節があります。 いちばんありがちなのは、 ある種の画面操作に対するパディング (62) が不足している場合です。 この種の問題があるかどうか調べるには、 他のメーカ製の別の端末でEmacsを動かしてみてください。 ある機種の端末では頻繁に問題が起きるのに別の機種の端末では問題がないなら、 termcapの定義がまちがっている可能性があります。 しかし、ある種の機能を有するか欠如している端末で現れる Emacsのバグである可能性もあります。
C-lを実行してもテキストが変ならば、 正しいと思われる状態になるまで、 C-x uを使って変更をもとに戻してみてください。 また、どのコマンドで変になったのか調べるために、 C-h lを試してみてください。
バッファの先頭や末尾で大量のテキストが失われているようなら、 モード行に単語`Narrow'が表示されていないか確認してください。 もしそうなら、おそらくテキストは失われているのではなく、 一時的に見えなくなっているのでしょう。 見えるようにするには、C-x n wと打ってください。 See section ナロイング。
Emacsが画面の最下行に自発的に`I-search:'と表示するようなら、 劣悪なxon/xoffの『フロー制御プロトコル』に従って 端末がC-sとC-qを送っているためでしょう。
もしこの状態が起きたら、もっともよいのは端末をフロー制御なしに設定するか、
または、パディングを十分に増やして端末がけっしてC-sを
送らないようにすることです。
(パディングを増やす1つの方法は、
より大きい値を変数baud-rate
に設定すること。
この値はボーという単位で表した端末の出力速度。)
フロー制御を止められない場合の次善の策は、
Emacsにフロー制御を処理させることです。
それには、関数enable-flow-control
を呼び出してください。
典型的な場合、
ある種の端末タイプに限ってフロー制御を使う必要があります。
enable-flow-control-on
を使って、
そのような種類の端末に限ってフロー制御を行うようにできます。
たとえば、VT-100端末とH19端末にはフロー制御を行う必要があるのなら、
ファイル`.emacs'につぎのものを入れます。
(enable-flow-control-on "vt100" "h19")
フロー制御を使っている場合には、C-sのかわりにC-\、 C-qのかわりにC-^を使う必要があります。 (これらの割り当てはキーボード変換によって行われる。 see section キーボード変換。)
`Virtual memory exceeded'というエラーメッセージが出たら、 変更したバッファをC-x sで保存してください。 この方法で保存する場合、必要なメモリは最小限ですみます。 Emacsは上記のエラーが起きたときでも使える予備のメモリを確保していますから、 C-x sを完了するのには十分なはずです。
変更済みのバッファを保存したら、 Emacsを終了して別のEmacsを起動してもよいですし、 M-x kill-some-bufferを使って 現在動いているEmacsのメモリを解放してもよいです。 大量のテキストが入っているバッファを消せば、 安全に編集を続行できます。 空きメモリが十分な量になると予備のメモリを自動的に確保し直し、 再度メモリ不足になったときに備えます。
メモリ不足になったときには、M-x buffer-menuを使って バッファを保存したり消したりしないでください。 このコマンドはけっこうメモリを必要とするので、 確保した予備のメモリだけでは十分でない可能性があるからです。
Emacsやコンピュータがクラッシュしても、 クラッシュ時に編集していたファイルは自動保存ファイルから回復できます。 それには、Emacsを再度起動してから、コマンドM-x recover-sessionを 入力してください。
このコマンドは、まず、中断されたセッションファイルの一覧を日付とともに バッファに表示します。 その中からどのセッションを回復するか選んでください。 通常は、最新のセッションを選べばよいでしょう。 望みのセッションの行にポイントを動かして、C-c C-cと打ちます。
すると、recover-session
は、そのセッションで編集中だった
各ファイルについて回復するかどうか問い合わせてきます。
yと答えると、そのファイルと自動保存ファイルの日付を表示してから、
回復するかどうか再度問い合わせてきます。
再問い合わせに対してはyesで答える必要があります。
そうすると、Emacsはそのファイルを訪れますが、
テキストは自動保存ファイルから持ってきます。
recover-session
が完了すると、
回復を指定したファイルはEmacsバッファに入っています。
そうしたらこれらのバッファを保存してください。
保存して始めてもとのファイルが更新されます。
バグのために、Emacsがquit-flag
を検査しないループに入ってしまうことも
ありえます。
このため、このフラグが設定されている状態で再度C-gが打たれると
ただちに実行を休止する特別な機能がEmacsにはあり、
いつでもGNU Emacsから抜け出すことができます。
通常、Emacsはすみやかにquit-flag
を認識し(中断し)ますから、
この特別な機能が使われることはまずありません。
(MS-DOSや互換システムでは、C-BREAKを2回連打する。)
C-gの連打によって休止したEmacsを再開すると、 Emacsは休止直前に実行していた動作に戻るまえに、 つぎの2つの質問をしてきます。
Auto-save? (y or n) Abort (and dump core)? (y or n)
それぞれの質問に対し、yかnに続けてRETで答えてください。
`Auto-save?'にyと答えると、 自動保存を行う設定になっている変更されたバッファすべてに対して ただちに自動保存を実行します。
`Abort (and dump core)?'にyと答えると、
Emacsは不正命令を実行してコアダンプを作ります。
コアダンプがあると、Emacsが中断できなかった理由をウィザード
(63)
が追究できます。
コアダンプを作り終えるとEmacsの実行は終了します。
nと答えると実行は継続します。
運がよければ、Emacsが最終的にはquit-flag
を検査して
正常に中断できるでしょう。
運が悪ければ、またループに入ったままになりますから、
再度C-gを打ってEmacsをまた休止します。
本当はEmacsが固まったのではなく単に遅いだけの場合には、 意図せずにC-gを連打してしまうことがあります。 その場合には、再開して2つの質問にnと答えればもとの状態に戻れます。 中断要求はすぐに受け付けられるでしょう。
XウィンドウシステムのもとでEmacsが動作している場合には、 C-g連打の機能は切ってあります。 というのは、ウィンドウマネージャを使ってEmacsを終了させたり、 別のウィンドウを開いて別のプログラムを動かせるからです。
MS-DOSや互換システムでは、 (MS-DOSやBIOSの)システムコールが固まっている場合や Emacsが非常にきつい(LispコードではなくCのコードで) 無限ループに入っている場合には、 C-BREAKを2回打っても緊急脱出の機能を使えない場合があります。
Emacsを使うこと(や、その他のこと)がきわめて不愉快になったり、 ここまでにあげたどの方法でも問題が解決しない場合でも、 Emacsはまだ手助けができます。
まず、Emacsがコマンドに応答しないようなら、 C-g C-gと打ってEmacsから抜け出し、 新たに別のEmacsを起動してください。
doctorプログラムがあなたのいらいらを鎮めてくれるでしょう。 doctorに何かを話すときには、RET RETと打っていい終える 必要があります。 こうすると、doctorは患者が話し終えたことを認識します。
Emacsのバグに出会うこともあるでしょう。 バグを修正する/できるとは約束できませんし、 そもそもバグだと認めないかもしれませんが、 読者が遭遇した問題については知らせてほしいと考えています。 たしかにそれをバグだと認めて修正しようということになる場合も多いのです。
バグを修正するには、まず、報告してもらう必要があります。 効果的に報告してもらうためには、報告の仕方を知っていただく必要があります。
Emacsが不正命令を実行したり、 (『ディスクが満杯』などの外部の問題ではなく)プログラムに問題が あるというオペレーティングシステムのメッセージを表示して止まった場合には、 たしかにバグがあるといえます。
Emacsの画面の更新結果がバッファの内容に対応していないなら、 それもたしかにバグです。 コマンドの実行が思わしくなくてもC-lで再表示させると正しくなる場合には、 画面更新がまちがっているのです。
あるコマンドを実行するのに無限に時間がかかるというのはバグの可能性が ありますが、たしかにEmacsの責任かどうかを確認する必要があります。 コマンドによってはとても時間がかかるものもあります。 C-g(MS-DOSではC-BREAK)を打ってから C-h lを打つことで、Emacsが受け付けた入力がたしかに 読者が意図したものだったかどうか確認できます。 すぐに処理されるコマンドだという確信があるなら、 バグを報告してください。 そのコマンドがすごく時間のかかるものかどうかわからないなら、 マニュアルで調べるか知っている人に聞いてください。
よく知っているコマンドであって、普通なら問題なく結果が得られるはずなのに、 かわりにEmacsがエラーメッセージを出すようなら、恐らくそれはバグでしょう。
コマンドが正しくない動作をするのなら、それはバグです。 ただし、コマンドが本当は何をするのが正しいか確認してください。 そのコマンドに馴染みがないとか、 そのコマンドがどう動作するはずなのか確信が持てない場合は、 コマンドは実際には正しく動作しているのかもしれません。 バグという結論に飛びつくまえに、よく知っている人に見てもらってください。
最後に、コマンドの意図された定義が編集操作に対して最良でない可能性があります。 これは重要な問題ではありますが、ユーザーがどう判断するかの問題でもあります。 既存の機能について無知なために、 まちがっていると結論を出してしまうのも簡単です。 まずドキュメントをひととおり調べて、十分に納得し、 それでもなお自分にとって必要な機能がない、と断言できるまでは、 コマンドの定義が悪いなどとはいわないほうがよいでしょう。 マニュアルを熟読してもコマンドが何をするのかよくわからなければ、 索引や用語集を活用してよくわからない単語について調べましょう。
十分熟読しても、なおコマンドが何をするのかわからないなら、 それは「マニュアルのバグ」として報告すべきでしょう。 マニュアルは、読者を含めて、Emacsの専門家でない人が読んでも すべてのことが明らかになるようなものであるべきです。 ドキュメントのバグを報告することも、 プログラムのバグを報告することと同じくらい重要なことです。
関数や変数のオンラインの説明文がマニュアルと一致しない場合は、 どちらかがまちがっていますから、これもバグです。
バグがあると確信したら、それを報告すること、 しかも、役立つ形で報告することが重要です。 もっとも有用なのは、どのようなコマンドを打ち込んだかを、 Emacsを起動するシェルのコマンドから始めて 問題が起きるところまですべて正確に記述することです。
バグを報告するときもっとも重要なことは事実を報告することです。 仮説や口頭説明は、詳細な生データのかわりにはなりません。 事実を報告することは単純なはずなのに、 多くの人はかわりに説明をでっちあげてそれを報告したがります。 その説明がEmacsの実装方式の想像に基づいたものであるならば、 その説明はまったく役に立たないでしょう。 事実が欠けていたらバグに関する真の情報を得られません。
たとえば、ユーザーがとても大きなファイルを訪れるために C-x C-f /glorp/baz.ugh RETと打ち込んだら、 Emacsが`I feel pretty today'と表示したとしましょう。 もっともよいバグレポートは、まさにこの文のように報告することです。 すべての事実だけを報告できるからです。
問題はファイルの大きさにあると仮定して、 「大きなファイルを訪問したら、Emacsが`I feel pretty today'と表示した」 などと書いてはいけません。 これが『説明をでっちあげた』報告です。 問題はファイル名に`z'が含まれていたために生じたのかもしれないのです。 もしそうだとしたら、報告に基づいて適当な「大きなファイル」を訪問してみても、 そのファイル名に`z'が含まれていなければ何も悪いところが みつからないでしょう。 報告の文面からは、名前に`z'を含んだファイルを 試しに訪問してみるべきだとはわかりません。
あるいは、ファイルがちょうど25個の空白文字で始まっているために
問題が起きたのかもしれません。
ですから、報告に際しては、そのバグを再現させるのに必要なファイルがあれば、
それらのファイルの正確な内容も教えてください。
その問題は、たまたま、C-x C-aと打った直後にのみ
発生するのだとしたらどうでしょう?
ですから、Emacsを起動してから問題に遭遇するまでに
打ち込んだものすべてを教えてほしいのです。
どの訪問コマンドを使っても同じように問題が発生すると知っている のでない限り、C-x C-fと打ったと報告するかわりに 「ファイルを訪問した」というのさえいけません。 同様に、「1行に3文字入っているとき」ではなく、 「RET A B C RET C-pと打ち込んだあとで」のように、 あなたがテキストを入れたやり方そのものを報告してください。
このように、バグを報告するときには、いかなる説明も推測しないでください。 問題を実際にデバッグして憶測ではない説明を報告してもらえるなら、 それは有益ですが、事実も含めてください。
バグレポートを送る最良の方法は、電子メイルでEmacs保守チーム `bug-gnu-emacs@gnu.org'に送ることです。 (重要な改良の提案などもここに送ってください)。
他から出されたバグレポートが読みたければ、 ニュースグループ`gnu.emacs.bug'で読めます。 ただし、傍観者として見る場合には、見たものについて批判するべきではない、 ということを承知しておいてください。 バグレポートの目的はEmacs保守チームに情報を提供することです。 傍観者は、この目的に干渉しない限りは、歓迎します。 特に、大量のデータが添付されているバグレポートもありますので、 傍観者はそのことを非難すべきではありません。
ネットニュース経由でバグレポートを投稿しないでください。 ネットニュースよりもメイルのほうが送り手のメイルアドレスが確実にわかり 信頼できます。 もっと情報が必要なときには、メイルで問い合わせる必要があるかも知れません。
電子メイルを送れない場合には、 紙や他の機械可読な媒体で下記へ送ってください。
GNU Emacs Bugs Free Software Foundation 59 Temple Place, Suite 330 Boston, MA 02111-1307 USA
バグを修正するとは約束できません。 しかし、重大なバグや、醜いバグや、簡単に直せるバグなら、直したいと思います。
Emacsのバグレポートを送るのに便利な方法の1つは、 コマンドM-x report-emacs-bugsを使うことです。 このコマンドはメイルバッファ(see section メイルの送信)を開いて、 自動的に重要な情報の一部を書き込みます。 しかし、必要な情報をすべて入れられるわけではありませんから、 以下の指針を読んでそれに従い、 メッセージを送るまえに重要な情報を自分で打ち込んでください。
保守チームがバグの調査を開始するためには、 以下のすべてがバグレポートに含まれている必要があります。
configure
コマンドの引数。
(open-dribble-file "~/dribble")それ以降はEmacsプロセスが終了するまで、 Emacsはすべての入力をドリブルファイルにコピーする。
TERM
の値)、
(すべてのマシンで同じとは限らないので)
`/etc/termcap'ファイル中の当該端末のtermcapの定義すべて、
および、Emacsが実際に端末に送った出力。
端末への出力を収集するには、Emacsを実行開始した直後に、M-:か
バッファ`*scratch*'でつぎのLisp式を実行する。
(open-termscript "~/termscript")それ以降、Emacsはプロセスが終了するまでのすべての端末出力の写しを 指定されたtermscriptファイルに書き出す。 Emacsが起動するときに問題が起きるのなら、 上の式を`.emacs'ファイルに入れて、 Emacsが最初に画面を開くときに一緒にtermscriptファイルも 書き始めるようにする。 ただし、端末に依存したバグは、 そのバグの出る端末なしで直すことは難しいことが多く、 ときとして不可能であることも承知しておいてほしい。
(setq debug-on-error t)
を評価する
(つまり、まずこのLisp式を実行して、それからエラーを再現させる)。
すると、エラーが起きたときにLispデバッガが実行され、
デバッガがバックトレースを表示する。
このデバッガのバックトレース出力を、バグレポートにコピーする。
このやり方は、バグを再現できるときだけ使える。
再現できない場合は、最低限、エラーメッセージだけでもすべてコピーする。
-q
を指定して初期化ファイルのロードを抑制して)
個人のファイル`.emacs'をロードせずに起動したEmacsでも
エラーが再現するかどうか調べる。
これでエラーが再現しないなら、
エラーの再現に必要なので、ロードしたすべてのプログラムの内容を正確に報告する。
pr
を使ってLispオブジェクトをLispの記法で
表示させる。
(別のデバッガを使わなければならない場合は、
オブジェクトを引数として関数debug_print
を呼び出す)。
コマンドpr
は、ファイル`.gdbinit'で定義されており、
(コアダンプではなく)実行中のプロセスをデバッグするときだけ使える。
Lispでエラーが発生したときにEmacsを中断してGDBに戻るようにするには、
Fsignal
にブレークポイントを設定する。
実行中のLisp関数の簡素な一覧を表示するには、
GDBのコマンドxbacktrace
を打つ。
Lisp関数の引数を調べたい場合には、
スタック上を上に移動していき関数Ffuncall
のフレームに到達するごとに、
つぎのようなGDBコマンドを打つ。
p *args pr関数が受け取った最初の引数を出力するには、つぎのようにする。
p args[1] pr2番目以降の引数でも同様に出力できる。
Ffuncall
の引数nargs
は、
Ffuncall
が受け取った引数の個数を表す。
この個数は、Lisp関数自身とその関数に対する引数とを合わせた数。
ファイル`.gdbinit'は、
データタイプやLispオブジェクトの中身を調べるのに役立つコマンド類を定義する。
それらのコマンドの名前は`x'で始まる。
これらのコマンドはpr
より下位のレベルで動作し使い難いが、
コアダンプをデバックしたり、
Emacsが致命的なシグナルを受理したときのように
pr
がうまく動かないときでも使える。
以下には、バグレポートに必要ないものをあげておきます。
pr
でLispオブジェクトとしても表示する(上記参照)。
GNU Emacsに対する改良や虫取りのための修正を送ろうということであれば、 おおいに助かります。 修正を送るにあたっては、保守チームがそれを役立てやすいように、 以下の指針に従ってください。 さもないと、送られた情報は有用であっても、 役立てるには余分な作業が必要になります。 GNU Emacsの保守は最善の環境でやっても手間のかかる仕事ですから、 手助けしていただくにしても十分な配慮が必要なのです。
Emacsのプレテスト版が正しく動作することの確認を手助けしたかったり、
Emacsの改良作業に加わりたければ、
bug-gun-emacs@gnu.org
の保守チームに連絡してください。
プレテスト参加者は、バグを報告するだけでなく、バグを探すことも要求されます。
Emacsの改良に加わりたければ、保守チームにプロジェクトの示唆を求めるか、
あなたのアイデアを提案してください。
すでに改良したコードを書いてしまったのなら、それについて教えてください。
まだ作業を始めていないのなら、始めるまえに
bug-gnu-emacs@gnu.org
に連絡したほうがよいです。
そうすれば、Emacsの残りの部分とよく適合する形で
拡張を行うにはどうしたらよいかのヒントがもらえるでしょう。
GNU Emacsをインストールしたり、使ったり、変更したりするうえで手助けが必要なら、 2つの方法があります。
help-gnu-emacs@gnu.org
にメッセージを送るか、
ニュースグループgnu.emacs.help
に投稿する。
(これらのメイリングリストとニュースグループは相互乗り入れしているので、
どちらを使ってもかまわない。)
Go to the first, previous, next, last section, table of contents.