Helmut Eller e9626484@stud3.tuwien.ac.at writes:
There's currently a bug in the protocol that you can see when trying to invoke restarts. In some cases the backends will want to send (:debug-condition <string>) messages to Emacs, but the Elisp code doesn't understand those messages anymore (due to my last "improvements"). In the automaton it would be nice to handle these messages in the `debugging' state, but since invoking a restart is done by RPC we end up in the `evaluating' state waiting for a result. So it seems nicer to control the debugger with asynchronous messages instead of RPCs.
Hehe, tricky. We could use asynchronous messages to call functions that are not supposed to return, right? If such a function enters the debugger, things would just work like they do now, but we would have to bind the *debugger-hook* somewhere. Alternatively we could add an event to the sate-machine that sends a RPC, but doesn't switch the state and ignores the :ok result.
Asynchronous evaluation sounds like a nice and expedient solution. A more perverse approach would be to make the return value a string saying what error caused it to return instead of aborting ;-)
BTW, a note to prospective backend implementors (hi Alain!): the "Evaluation mechanics" (outline mode) section of slime.el has commentary/code describing the SLIME protocol, i.e. what you can SEND-TO-EMACS and in which order. This isn't explicit in the backend code (yet).
Another thought: would it be possible to run the state machine from a an idle timer (with a very small timeout) instead from the process filter? Would that solve the problem with loosing input when someone throws out from the state machine?
Worth a try!
That's cool. We should perhaps ask before disconnecting, just in case someone has significant state on the stack.
Yeah. In general I think the stack is hosed once you reach an inconsistent state, but that's not true of this :debug-condition problem - it can be "ignored" since it doesn't cause a state change. Probably should have something like:
Inconsistent protocol state: (c)ontinue, (d)isconnect, (r)econnect?
Cheers, Luke