バグがあると判断したときはそれを報告すること、そして有用な方法で報告することが重要です。もっとも有用なのは、Emacsを起動するシェルコマンドから、問題が発生するまで、何のコマンドをタイプしたか、そしてそれらのコマンドをタイプしたことにより生成された効果に関する正確な記述です。
バグレポートのもっとも重要な原理は、事実を報告することです。仮定や口頭の説明は、詳細な生データの代替にはなりません。事実の報告は簡単ですが、多くの人は事実のかわりに仮定の説明をしようと懸命に努め、それを報告するのです。その説明がEmacsが実装されている方法にたいする仮定にもとづく場合、それらは役に立たないかもしれません。その一方で事実の欠落により、わたしたちはバグについての実際の情報を得られないでしょう。実際に問題をデバッグして、推定を超える説明を報告したい場合、それは有用です — しかし、どうか生の事実も同様に含めてください。
たとえば、C-x C-f /glorp/baz.ugh RETとタイプして、ファイルをvisitしたとき、そのファイルが偶然大きい(とあなたは知っている)ファイルで、Emacsが‘I feel pretty today’と表示したとします。バグレポートにはすべての情報が必要になります。あなたは問題がファイルのサイズにあると仮定して、“大きなファイルをvisitしたら、Emacsが‘I feel pretty today’と表示します”、などと報告すべきではありません。これはわたしたちが“推測説明(guessing explanations)”と呼ぶものです。ファイル名に‘z’があるという事実が、問題の原因かもしれません。もしそうなら、あなたの報告を受け取ったとき、わたしたちは大きなファイルで問題の再現を試み、それらのファイル名にはおそらく‘z’が含まれておらず、問題を確認できないでしょう。名前に‘z’が含まれるファイルをvisitしてみるべきだと、推測できる方法はありません。
C-x C-fはおろか、“ファイルをvisitして”とさえ言うべきではありません。なぜならファイルがvisitされる方法は複数あり、それらの方法すべてにおいて問題が再現されるか確証がないからです。同様にテキストを入力する方法では、“その行に3文字あるとき”ではなく、もしもテキストを入力したのであれば“RET A B C RET C-pとタイプした後”、すなわちあなたの場合に問題が発生したテキストについて教えてください。
可能なら、すぐにバグを再現するためにemacs -Q(Emacsは初期のカスタマイズなしで開始されます。初期化オプションを参照してください)でEmacsを呼び出して、バグを発生させるステップを繰り返してみてください。この方法でバグを再現できたら、あなたの個人的なカスタマイズをバグから除外して、バグが容易に再現するようにしてください。バグレポートは、Emacsをemacs
-Qで開始したことから始まり、バグを再現させる正確な一連のステップを続けるべきです。可能ならバグを再現するのに必要な、正確なファイル内容を報告してください。
emacs
-Qでは再現できないバグもいくつかあります。結局は再現するのが難しいバグもあります。そのような場合、何を行なったかを報告すべきです —
が、前述したように、どうか最初にバグを発生させた生の事実を固持してください。
報告したい複数の問題がある場合は、どうかそれらを個別のバグとしてそれぞれ報告してください。