バグがあると判断した際は、それを報告すること、そして有用な形で報告することが重要です。最も有用なのは、Emacsを起動するためのシェルコマンドから始まり、問題が発生するまでの一連のコマンドと、それらのコマンドを入力した際に生じた影響について、正確に記述することです。
バグを報告する際の最も重要な原則は、事実を報告することです。仮説や言葉による説明は、詳細な生データの代わりにはなりません。事実を報告することは単純ですが、多くの人は事実の代わりに説明を導き出し、それを報告しようと躍起になります。もしその説明がEmacsの実装に関する推測に基づいているなら、有用ではないかもしれません。一方で、事実がなければ、そのバグに関する実質的な情報を得ることはできません。問題を実際にデバッグしたい場合や、推測を超えた説明を報告したいのであれば、それは有用です—ただし、生の事実も併せて記載してください。
例えば、C-x C-f /glorp/baz.ugh RET と入力して、（ご存知の通り）かなりサイズの大きいファイルを開いたところ、Emacs が ‘I feel pretty today’ と表示したとします。バグレポートには、こうした情報をすべて記載する必要があります。問題がファイルのサイズに起因すると決めつけて、「大きなファイルを開いたところ、Emacs が ‘I feel pretty today’ と表示した」などと書いてはいけません。これが、いわゆる「説明を推測する」ということです。問題の原因は、ファイル名に ‘z’ が含まれていることにあるのかもしれません。もしそうであれば、レポートを受け取った際、おそらくファイル名に ‘z’ が含まれていない何らかの大きなファイルで問題を検証しても、何も問題は見つからないでしょう。ファイル名に ‘z’ が含まれるファイルを開いて試すべきだと推測するなど、到底不可能です。
C-x C-fの代わりに「ファイルにアクセスする」などと言うべきではありません。というのも、ファイルへのアクセス方法は複数の場合があり、それらすべてで問題が再現するとは限らないからです。同様に、「1行に3文字ある場合」と言うのではなく、もしそのようにテキストを入力したのであれば、「RET A B C RET C-pと入力した後」と言ってください。つまり、あなたの場合、どのようなテキストが問題を引き起こしたのかを教えてください。
可能であれば、emacs -Q を指定して Emacs を起動し（これにより Emacs
は初期カスタマイズなしで起動します。初期オプション
を参照してください）、バグを発生させた際の手順を再現することで、速やかにバグの再現を試みてください。この方法でバグを再現できれば、個人のカスタマイズに起因するバグの可能性を排除でき、再現も格段に容易になります。その場合、バグレポートの冒頭に
emacs -Q で Emacs
を起動したことを明記し、続いてバグを再現するための正確な手順を記載してください。可能であれば、バグの再現に必要なファイルの正確な内容についてもお知らせください。
emacs
-Qからは再現できないバグもあれば、そもそも容易に再現できないものもあります。その場合は、現状を報告してください。ただし、前述の通り、最初にバグを発生させるために何を行ったかという生の事実に徹してください。
報告したい問題が複数ある場合は、それぞれ個別にバグレポートを作成してください。