Next: , Up: Bugs


28.10.1 バグの発生時期

Emacsが不正命令を実行したり、 (『ディスクが満杯』などの外部の問題ではなく)プログラムに問題が あるというオペレーティングシステムのメッセージを表示して止まった場合には、 たしかにバグがあるといえます。

Emacsの画面の更新結果がバッファの内容に対応していないなら、 それもたしかにバグです。 コマンドの実行が思わしくなくてもC-lで再表示させると正しくなる場合には、 画面更新がまちがっているのです。

あるコマンドを実行するのに無限に時間がかかるというのはバグの可能性が ありますが、たしかにEmacsの責任かどうかを確認する必要があります。 コマンドによってはとても時間がかかるものもあります。 C-g(MS-DOSではC-<BREAK>)を打ってから C-h lを打つことで、Emacsが受け付けた入力がたしかに 読者が意図したものだったかどうか確認できます。 すぐに処理されるコマンドだという確信があるなら、 バグを報告してください。 そのコマンドがすごく時間のかかるものかどうかわからないなら、 マニュアルで調べるか知っている人に聞いてください。

よく知っているコマンドであって、普通なら問題なく結果が得られるはずなのに、 かわりにEmacsがエラーメッセージを出すようなら、恐らくそれはバグでしょう。

コマンドが正しくない動作をするのなら、それはバグです。 ただし、コマンドが本当は何をするのが正しいか確認してください。 そのコマンドに馴染みがないとか、 そのコマンドがどう動作するはずなのか確信が持てない場合は、 コマンドは実際には正しく動作しているのかもしれません。 バグという結論に飛びつくまえに、よく知っている人に見てもらってください。

最後に、コマンドの意図された定義が編集操作に対して最良でない可能性があります。 これは重要な問題ではありますが、ユーザーがどう判断するかの問題でもあります。 既存の機能について無知なために、 まちがっていると結論を出してしまうのも簡単です。 まずドキュメントをひととおり調べて、十分に納得し、 それでもなお自分にとって必要な機能がない、と断言できるまでは、 コマンドの定義が悪いなどとはいわないほうがよいでしょう。 マニュアルを熟読してもコマンドが何をするのかよくわからなければ、 索引や用語集を活用してよくわからない単語について調べましょう。

十分熟読しても、なおコマンドが何をするのかわからないなら、 それは「マニュアルのバグ」として報告すべきでしょう。 マニュアルは、読者を含めて、Emacsの専門家でない人が読んでも すべてのことが明らかになるようなものであるべきです。 ドキュメントのバグを報告することも、 プログラムのバグを報告することと同じくらい重要なことです。

関数や変数のオンラインの説明文がマニュアルと一致しない場合は、 どちらかがまちがっていますから、これもバグです。