gnus: Troubleshooting
11.6 Troubleshooting
====================
Gnus works _so_ well straight out of the box—I can’t imagine any
problems, really.
Ahem.
1. Make sure your computer is switched on.
2. Make sure that you really load the current Gnus version. If you
have been running GNUS, you need to exit Emacs and start it up
again before Gnus will work.
3. Try doing an ‘M-x gnus-version’. If you get something that looks
like ‘Gnus v5.13’ you have the right files loaded. Otherwise you
have some old ‘.el’ files lying around. Delete these.
4. Read the help group (‘G h’ in the group buffer) for a FAQ and a
how-to.
5. Gnus works on many recursive structures, and in some extreme (and
very rare) cases Gnus may recurse down “too deeply” and Emacs will
beep at you. If this happens to you, set ‘max-lisp-eval-depth’ to
500 or something like that.
If all else fails, report the problem as a bug.
If you find a bug in Gnus, you can report it with the ‘M-x gnus-bug’
command. ‘M-x set-variable RET debug-on-error RET t RET’, and send me
the backtrace. I will fix bugs, but I can only fix them if you send me
a precise description as to how to reproduce the bug.
You really can never be too detailed in a bug report. Always use the
‘M-x gnus-bug’ command when you make bug reports, even if it creates a
10Kb mail each time you use it, and even if you have sent me your
environment 500 times before. I don’t care. I want the full info each
time.
It is also important to remember that I have no memory whatsoever.
If you send a bug report, and I send you a reply, and then you just send
back “No, it’s not! Moron!”, I will have no idea what you are insulting
me about. Always over-explain everything. It’s much easier for all of
us—if I don’t have all the information I need, I will just mail you and
ask for more info, and everything takes more time.
If the problem you’re seeing is very visual, and you can’t quite
explain it, copy the Emacs window to a file (with ‘xwd’, for instance),
put it somewhere it can be reached, and include the URL of the picture
in the bug report.
If you would like to contribute a patch to fix bugs or make
improvements, please produce the patch using ‘diff -u’.
If you want to debug your problem further before reporting, possibly
in order to solve the problem yourself and send a patch, you can use
edebug. Debugging Lisp code is documented in the Elisp manual (
Debugging Lisp Programs (elisp)Debugging.). To get you started with
edebug, consider if you discover some weird behavior when pressing ‘c’,
the first step is to do ‘C-h k c’ and click on the hyperlink (Emacs
only) in the documentation buffer that leads you to the function
definition, then press ‘M-x edebug-defun RET’ with point inside that
function, return to Gnus and press ‘c’ to invoke the code. You will be
placed in the lisp buffer and can single step using ‘SPC’ and evaluate
expressions using ‘M-:’ or inspect variables using ‘C-h v’, abort
execution with ‘q’, and resume execution with ‘c’ or ‘g’.
Sometimes, a problem do not directly generate an elisp error but
manifests itself by causing Gnus to be very slow. In these cases, you
can use ‘M-x toggle-debug-on-quit’ and press ‘C-g’ when things are slow,
and then try to analyze the backtrace (repeating the procedure helps
isolating the real problem areas).
A fancier approach is to use the elisp profiler, ELP. The profiler
is (or should be) fully documented elsewhere, but to get you started
there are a few steps that need to be followed. First, instrument the
part of Gnus you are interested in for profiling, e.g., ‘M-x
elp-instrument-package RET gnus’ or ‘M-x elp-instrument-package RET
message’. Then perform the operation that is slow and press ‘M-x
elp-results’. You will then see which operations that takes time, and
can debug them further. If the entire operation takes much longer than
the time spent in the slowest function in the profiler output, you
probably profiled the wrong part of Gnus. To reset profiling
statistics, use ‘M-x elp-reset-all’. ‘M-x elp-restore-all’ is supposed
to remove profiling, but given the complexities and dynamic code
generation in Gnus, it might not always work perfectly.
If you just need help, you are better off asking on ‘gnu.emacs.gnus’.
I’m not very helpful. You can also ask on the ding mailing list
<ding@gnus.org>. Write to <ding-request@gnus.org> to subscribe.