Luke Gorrie luke@bluetail.com writes:
Maybe a better idea would have been to go for chaos? We send N requests to Lisp at a time, and it replies in any order (with an ID tag to identify the result), we can get multiple unknown threads hitting the debugger at the same time, etc.
I tried to remove the state machine some time ago, but wasn't very successful. The id argument in eval-string stems from that attempt.
Here some problems I encountered:
The current state stack contains (state-name . variables) pairs. It wasn't obvious to me where I should store the variables instead. Including the variables in the request itself doesn't work, because the variables contain things like window configurations. Storing them in a buffer -- e.g., the variables of the debugging state in the sldb buffer -- doesn't work because the user can delete the buffer. So I stored them on a stack again :-)
Another problem was that there where no 'activate' events anymore. When you exited from the debugger at level 3 to level 2, Emacs didn't notice it. My idea was to generate the activate events at the Lisp side. So I changed the Lisp sldb-loop and sent an 'activate-debugger' event every time before reading the next request. The sldb-loop looked like this:
(send-to-emacs '(:initialize-debugger ...)) (loop (send-to-emacs '(:activate-debugger ...)) (read-from-emacs))
This too was problematic, because the :initialize-debugger event could cause a RPC from Emacs to Lisp (e.g., fetching the backtrace). But the result of the RPC arrived after the :activate-event. I gave at this point.
I think we cannot blindly accept every event at any time. Maybe we need something like a mailbox with Erlang-style selective receive :-)
Helmut.