Luke Gorrie luke@bluetail.com writes:
Peter Seibel peter@javamonkey.com writes:
Are you planning to make it possible to debug multiple threads simultaneously--I.e. it might be nice to set break points in two places that will be hit be different threads and then debug them both at the same time (in two different debugging buffers); for example step a little way in one thread, then switch to the other; etc.
Not initially. Is that something you need?
Not initially. ;-)
This is slightly tricky in SLIME because we support a synchronous evaluation interface in Emacs Lisp. In Elisp you can write:
(slime-eval '(swank:some-function))And it will evaluate the form in Lisp and then return the result. However, it might enter the debugger before it finishes, in which case Emacs enters a "recursive edit" to do the debugging without unwinding the Elisp stack (so that when you finish debugging it can return the final result to the `slime-eval' call). If during debugging you switched over to another thread and did another `slime-eval' there, the stack would end up rather tangled -- you have two `slime-eval's on the stack and have to return to one before the other.
A few possible solutions come to mind, but I think it will be better to burn this bridge when we come to it and do some experimentation. Ideas are always welcome, of course.
Hmmm. I'm pretty ignorant of the details of recursive edits. Which gives me the advantage of not knowing what's hard. ;-) Here's how I was envisioning it: when I pick a thread to debug from the list of debuggable therads SLIME creates a new buffer for interacting with that thread. I switch between threads by switching between buffers. Thus I can C-x 2 to split my window and put one thread-buffer in each window and switch back and forth with C-x o. Peeking at the info page for recursive edits I see this:
In general, we try to minimize the use of recursive editing levels in GNU Emacs. This is because they constrain you to "go back" in a particular order--from the innermost level toward the top level. When possible, we present different activities in separate buffers ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ so that you can switch between them as you please.Some commands ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ switch to a new major mode which provides a command to switch back. These approaches give you more flexibility to go back to unfinished tasks in the order you choose.
I'm not sure I grok all the implications of that underlined portion but it sort of sounds like if you were following that advice instead of debugging in a recursive edit you'd debug in a new buffer. Which you might switch to automatically if you're interacting with the Lisp synchronously.
-Peter