\nAll the cool kids use debuggers for debugging their code. In most situations that’s the right answer. After all, you can set breakpoints, step through your code, and examine values at each step. If you want a detailed view into what your code is doing, debuggers are the best solution.\n<\/p>\n
\nSometimes, though, they’re a bit heavy weight and way more than you need. Often all you need is a few strategically placed \nMarcin Borkowski (mbork) has a nice example of the latter<\/a>. He was debugging an Elisp function that messed with windows and that interfered with Edebug<\/a>’s use of those windows. The answer, of course, was to fall back to the \nThen he noticed that virtually all his invocations were of the form \nMbork’s post is well worth reading and his code is worth a bit of study too. I like the way he just digs in and solves the problems without too much worry about whether or not it’s the best way. At the end of the day, he solved his problem and that’s what matters.<\/p>\n","protected":false},"excerpt":{"rendered":" All the cool kids use debuggers for debugging their code. In most situations that’s the right answer. After all, you can set breakpoints, step through your code, and examine values at each step. If you want a detailed view into … Continue reading printf<\/code>\u200bs to get the necessary information to solve the problem. Sometimes, for various reasons, you can’t use a debugger so you’re forced to fall back on printf<\/code>.\n<\/p>\nprintf<\/code> method. The natural solution was to use the Elisp message<\/code> function but there were some problems. The first problem was easy. The messages appeared in the minibuffer and disappeared before he could read them. He fixed that by wrapping message<\/code> in a function that waited for a key press before continuing.\n<\/p>\n(message \"var1: %s, var2: %s\" var1 var2)<\/code>, and that it made sense to abstract that a bit into a new function. That brought a couple of new problems but they were also easily dealt with.\n<\/p>\n