Troubleshooting techniques for Emacs and Elisp

Question

I've been a fairly regular emacs user for about 4 years, but I'm still a newbie when it comes to customizing emacs and troubleshooting elisp. Recently, I've started customizing emacs as my ruby development environment and I've learned a few techniques from the folks here in StackOverflow. For example, some one here told me about C-u C-M-x to instrument a function with edebug and then step thru' the code. I also figured out that most commands and modes in emacs provide tons of hooks (either functions or regexps or customizable variables) which will provide most of what any newbie would want.
Now I'm greedy - I'm looking for more techniques and tips you've used and found useful in the past.

Answer 1

 (setq debug-on-error t)
 (setq debug-on-quit t)

Those help when you want to debug arbitrarily deep problems. You've already discovered edebug (which is my tool of choice for figuring out other people's code). describe-function usually gives you a link to the .el file (along with line number) where it was loaded. That's useful to jump to the source of the problem. I often do that, copy out the function, put in some message calls and re-evaluate C-x C-e to have that run instead of the original.

Answer 2

C-x Esc Esc gives you a browsable history of M-x commands you have run, but shows you the elisp code.

IELM is a repl for emacs lisp.

Speedbar is an excellent way to browse your .el files, alsoI find myself using C-h i frequently (to browse the elisp manual) and using speedbar to browse the node tree of topics.

C-s / C-r incremental search in the info browser will actually search past page breaks.

I often run M-: to test a quick bit of code without having to switch to my *ielm* buffer.

For especially tricky code I make a shortcut on my desktop to run emacs -q -l development-init.el (this is especially handy with code that deals with low level manipulations on buffers and external processes, the kind of thing that can easily hang emacs or kill it with a segv).

Answer 3

If hacking your .emacs file, always leave an emacs process running, and test the changes (with --debug-init) by starting a second Emacs process. This way, if there are problems, you still have an editor up that you can work in.