Go to the first, previous, next, last section, table of contents.

バグの報告

ときにはEmacsのバグに出合うこともあるでしょう.我々はそのバグを必ず直 せるとは限りませんし,また,それがバグであるということに同意すらしないか もしれませんが,直したいと考える場合には利用者の見つけたバグについての情 報がなくてはなりません.

我々がバグを直すためには利用者にそれを報告していただく必要があります. この報告を効果的に行なうために,利用者はいつ,どうやって報告したらよいか を知っておいてください.

どんなときがバグか

Emacsが不正命令を実行したりプログラムに問題があるというオペレーティン グ・システムのエラーメッセージ("disk full"のようなものではなく)が出て, 止まってしまった場合,それは確かにバグです.

Emacsがバッファにあるものに対応しない表示をしたら,これは確かにバグで す.コマンドが誤った実行をしているように見えても,C-lを入力したら 問題が解消されたときは,表示更新が正しくなかったケースです.

いつまでたってもコマンドが完了しない場合もバグである可能性がありますが, 本当にEmacs側のバグなのかどうか確かめてみてください.実行に長い時間のか かるコマンドもいくつかあります.C-gのあと,C-h lを入力して Emacsが受け付けた入力が利用者の意図したものであったかどうか確かめてくだ さい.すぐに実行されるはずと知っているコマンドであった場合にはバグを報告 してください.そのコマンドが長い時間を要するかどうか知らない場合は,マニュ アルを見るか誰かに助けてもらってください.

利用者のよく知っているコマンドを実行したときに,その定義が正しいもので あるのにEmacsのエラーメッセージが出た場合にはそれはおそらくバグでしょう.

コマンドが間違ったことを実行した場合にはそれはバグです.しかしその前に, コマンドが本当は何をするものなのかが分かっているかどうか自問してみてくだ さい.もし利用者がそのコマンドをあまり知らなかったり,そのコマンドがどの ような動作をするのか,はっきりとは知らない場合には,そのコマンドは正しく 動作している可能性もあります.すぐに結論に飛びつくのではなく,よく知って いる人にその問題を見てもらいましょう.

最後に,コマンドで意図された定義が編集には最適でないこともあります.こ れは大変重要な問題ですが,また判断の問題でもあります.また,ある機能を知 らないためにそういった結論に達しやすいともいえます.いつものやり方でまず 説明文書を調べ,それを理解しているという確信が持て,それでも望みの機能が 実現されていないと確信したら,そこではじめて"問題がある"と結論するのが もっともよい方法です.マニュアルをよく読んでも,そのコマンドが何をするは ずなのかがはっきりと分からない場合には,不明確な言葉を索引や用語集で調べ ましょう.それでも分からない場合はマニュアルにバグがあるといえるでしょう. マニュアルによって"すべて分からなければ"なりません.マニュアルのバグを 報告することはプログラムのバグの報告と同じくらい重要です.

ある関数や変数のオンラインでの説明文書がマニュアルと矛盾している場合に はいずれかが間違っているはずなのでバグを報告してください.

バグの報告の方法

バグであると判断したときにそれを報告すること,しかも役に立つように報告 することが重要です.最も役に立つのは利用者の入力したコマンド,つまり Emacsをスタートさせたシェルコマンドから,問題が起こるまでに入力したコマ ンドの正確な記述です.また使っているEmacsのバージョン番号も含めてください. これを得るにはM-x emacs-versionと入力します.

バグを報告するときにもっとも重要な原則は,仮説やバグの種類ではなく," 事実"を報告することです.事実を報告する方がやさしいはずですが,人々は説 明しようと努力し,事実の代わりにそれを報告してしまうことが多いようです. 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と入力したら"と報告してください.

問題が発生したときFundamentalモードでなかった場合は,どのモードにいた のかも報告してください.

Emacsのエラーメッセージによってバグが明らかになったのなら,エラーメッ セージのテキストだけではなく,EmacsのLispプログラムが,どうやってそのエ ラーのところまできたかというバックトレースを報告することが大切です.バッ クトレースを得るにはエラーが起きる前にLisp式(setq debug-on-error t)を実行する必要があります(すなわちこの式を実行した あと,もう一度バグを発生させるわけです).これによりLispデバッガが動作し ます(see section Emacs Lispデバッガ).デバッガのバックトレースも,バグ報告にテキスト としてコピーすることができます.このデバッガの使い方は,そのバグを再現す る方法を知っている場合のみ可能です.最初にバグが起こったときにかならずエ ラーメッセージを記録しておいてください.バグが再現しなかったら,それだけ でも報告してください.

利用者がLisp環境にロードしたプログラム(利用者の`.emacs'ファイルも 含む)が,Emacsの機能に影響を与えるような変数の設定を行なっていないか調べ てください.また利用者の`.emacs'ファイルをロードせずに始動したEmacs でも問題が発生するかどうかを調べてください(-qスイッチを付けて Emacsをスタートすると初期化ファイルのロードをしません).そのときに問題が 起きなければ,問題を起こすためLisp環境にロードしなくてはならないプログラ ムの具体的内容を我々が知ることが重要になります.

その問題が初期化ファイルや標準のEmacsのシステムの一部ではないような他 のLispプログラムに由来しているならば,それはメインテナンスをしている人に 相談してプログラムのバグではないということをまず確認する必要があります. Emacsが正しい動作をするような設定で使用していると確認したら,バグを報告 してください.

ファイルの読み込みをせずに問題が発生する場合が見つかったら,それも報告 してください.これでデバッグがずっとやりやすくなります.ファイルが必要な らその正確な内容を我々が見られるようにしてください.たとえばファイルの最 後の空白や,バッファの最終行の次の改行が影響することがよくあります.(最 終行が終っているかどうかは気にする必要はありませんが,バグに関係すること があります.)

Emacsへの入力を正確に記録する簡単な方法は,ドリブルファイルを作ること です.これには次のLisp式を実行します.

(open-dribble-file "~/dribble")

これにはMeta-ESCを使うかEmacsをスタートした直後の `*scratch*'バッファから呼び出します.これを実行してからは,Emacsの プロセスが終了するまではEmacsへのすべての入力は指定されたドリブルファイ ルに書き込まれます.

表示のバグである可能性があるときには端末の種類(環境変数TERMの値), その端末に対する`/etc/termcap'のエントリの全体(このファイルはすべて のマシンに共通ではないからです),およびEmacsが実際に端末に送った出力を報 告してください.この出力を得るには,次のLisp式を実行します.

(open-termscript "~/termscript")

これにはMeta-ESCを使うか,Emacsをスタートした直後の `*scratch*'バッファから呼び出します.これを実行してからEmacsのプロ セスが終了するまで,Emacsから端末へのすべての出力が指定された端末記録ファ イルに書き込まれます.Emacsが始動したときに問題が生じるなら,この式をあ なたの`.emacs'ファイルに入れます.これによりEmacsがはじめて画面表示 を行なうときには,すでに端末記録ファイルがオープンされているようになりま す.注意:端末に由来するバグを修正するのは,そのバグが発生する端末に直接 触れない限り,困難あるいは,ときには不可能です.

バグを報告する住所は

GNU Emacs Bugs
545 Tech Sq, rm 703
Cambridge, MA 02139

あるいはUsenetの`mit-eddie!bug-gnu-emacs'またはInternetの `bug-gnu-emacs@prep.ai.mit.edu'にメイルを送ってください.

繰り返しますが,我々は必ずそのバグを直すとはお約束できません.しかしそ のバグが重大なもの,みっともないもの,簡単に直せるもの,である場合には我々 がそれを直したいと考える可能性は高いでしょう.

Emacs Version 17 Antinews

For those of you who are downgrading from version 18 to version 17 of GNU Emacs, here is a list of the old features. You will note many simplifications; complicated features have been eliminated. The list does not include changes affecting only topics not dealt with in this manual.

General Changes

Changes in Major Modes

Init Files and Library Changes


Go to the first, previous, next, last section, table of contents.