Wed Jun 6 20:11:44 CEST 2007
using it for a bit, it's clear that async IO is necessary. for the
rest it works pretty well. so i need these operation schemes:
* synchronous evaluation: obtain value from scheme -> emacs,
independent of the currently running task.
* commands: set some process in motion, and let it print to the buffer
output, possibly executing emacs code.
what about this: all messages are asynchronous on the emacs
side. synchronous is built on top of asynchronous, by waiting on a
reply, and updating all buffer filters during waiting. this is how it
the change would be: scheme side can return multiple output replies,
but the value needs to go to a proper receiver. i think this solves
it: scheme just needs to treat output and values differently, sending
output always to the buffer, and reply to the receiver requested by
so, basicly, it's just as ordinary inferior processes, only the stuff
that comes back is tagged (embedded in s-expressions), giving several
logical channels. two of them are ordinary output, and emacs code
invokation. (ordinary output is a special case of emacs code
invokation, in short: everything that returns is evaluated).
now, the difference between a synchronous and an asynchronous reply is
that the former has some code waiting. i could probably unify both of
them, by having the async reply always store the values and errors in
some dummy global variable: normally, there should be no value, since
for async commands, either output is generated, or some other elisp
code is run.