Over at Emacs Redux, Bozhidar Batsov has a nice post on Emacs debugging commands. It’s not the first time that I’ve written about this sort of thing (see here, for instance) but unless you’re actively developing in Elisp, you probably aren’t going to need these techniques very often.
Still, all of us sometimes experience an Emacs command aborting with an error. Usually—not always, but usually—this isn’t a software error but results from a misconfiguration or at least an usual configuration. Most Irreal readers probably have enough technical chops to do some simple debugging and resolve the problem without reaching out to experts. The value of Batsov’s post is that it provides a short recipe for doing that.
The first thing to do is to enable debug-on-error. That will give you a backtrace to help you see where your command is failing. Batsov says you can turn this on permanently in your init.el but I found that this dumped me into the debugger for mundane errors that were caused by user input. It’s better in my opinion to enable it temporarily and rerun the command that’s misbehaving.
“Backtrace” may seem a little scary but often seeing what functions are being called and what their arguments are will tell you immediately what the problem is. You definitely don’t have to be an Elisp expert to take advantage of this.
If debug-on-error is not enough you can set a breakpoint on the problem command and step through it. That really does sound scary but it’s not. Batsov gives a simple 4-step procedure to set it up and tells you how to step through the code. This is almost always enough to find the problem.
There is, as Batsov says, a lot of built-on debugging capability in Emacs and it’s worthwhile getting familiar with it.