Thu May 22 15:28:00 CEST 2008

better emacs channel

This is a redesign of the emacs<->mzscheme communication in snot,
using a simpler architecture where mzscheme does most of the logic.

Previous design had the following problems:

 * repl not intelligent enough to understand the different languages used.
 * differences in elisp <-> scheme syntax
 * problematic multiplexing of data over a single channel

The core idea now is: keep the emacs side dumb. All significant
processing should be done in the scheme side, possibly also providing
the emacs side with code initializations.

Where to start?

   ** create a bidirectional asynchronous message channel **
What about using emacsclient for scheme->emacs? One of the things i
got annoyed about is that there's no way to perform a read from a
stream to produce a single message without hassle. emacsclient does
provide delimited messages.

Sending messages the other way could be done using a similar
'mzclient' application. Using socat is probably the easiest way.

I'm thinking about just using unix sockets on the scheme side, but
this is not portable. INET sockets are portable, but not
authenticated.. Let's stick to unix, and make the mechanism pluggable

using  (planet "socket.ss" ("vyzo" "socket.plt" 1 2))
but i can't get it to work with PF_UNIX

maybe i concentrate on just stdin.

i ignored a problem: some code in emacs will need a blocking rpc
semantics. how to do that?