[slime-devel] more stuff

[Luke Gorrie]

Helmut Eller <e9626484 at 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