Gnus works so well straight out of the box—I can’t imagine any problems, really.
Ahem.
max-lisp-eval-depth to 2000 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 toggle-debug-on-error, 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 (see Debugging Lisp Programs in The GNU Emacs Lisp Reference Manual). 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 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 Emacs Lisp 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. Write to ding-request@gnus.org to subscribe.