[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Elegance in elisp, need advices

From: Luke Gorrie
Subject: Re: Elegance in elisp, need advices
Date: 03 Feb 2003 01:30:40 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

"Stefan Monnier <>" 
<monnier+gnu.emacs.sources/news/> writes:

> [ redirecting follow-ups to ]
> > For instance, the connection is set up with open-network-stream and
> > set-process-filter. I keep a buffer-like string (buffer as in C not as
> > in emacs), to which I concatenate every received string. When I am
> [...]
> > What would be the 'good' way to do that ?
> Other than details of the layout of your code (more than 80 cols, docstring
> on the same line as the `defun', ...) it looks OK.  I don't know of any way
> to make it much better.  You could of course use a real Emacs buffer rather
> than a string, so you can use `insert / delete-region' rather than
> `concat / substring', but fundamentally, it can't be very different.
> Admittedly, many process filters do such things, so it might be worth it
> to provide a generic way to solve it, but I don't know of anybody who's
> done that yet.

I have something like this, it's a simple library for writing
network-attached state machines. It basically gives your process
buffer a "state", which is the name of a function to call when
something happens (initialization, data arrives, disconnection.) Like
a sentinel+filter, but I also accumulate data in the buffer itself

The state machine also has a function to call if it terminates
successfully and one to call if it fails (explicitly or via lisp
error.) This is nice if you want to deliver the final result of your
connection to some other code.

When data arrives, the state function will typically check the buffer
to see if a whole message is there, and if not just return (to be
reinvoked when more data arrives), otherwise consume the message and
possibly change states.

It also has some debugging support, via an *fsm-debug* buffer that
logs events and state changes.

It's not properly documented, but the code is here (net-fsm.el):

It was mostly written to support an implementation of the Distributed
Erlang state machine (derl.el):

A simpler machine talks to the Erlang Port Mapper Daemon (epmd.el):

If this sounds interesting but the code is too opaque, let me know and
I'll document it when I have a chance.

BTW, Emacs buffers (rather than strings) make exquisite network
buffers I reckon, since you can interactively switch into them and
call your data-reading functions via M-: or the debugger, and see the
point advance through the input, etc. I love it a lot for debugging.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]