On Thu, 3 Feb 2011 12:06:20 -0500, Austin Clements <amdragon@mit.edu> wrote:
> Nice catch.
> 
> Is there a reason you keep the remaining data in a string instead of
> taking the more idiomatic elisp approach of leaving it in the process
> buffer?

Thomas is excused since he was just modifying my code originally.

And now I've gone and made it even worse by adding a bunch of hideously
non-idiomatic expressions like:

	(while (and (< line (length string)) (= (elt string line) ?\n))
	  (setq line (1+ line)))

The rough equivalent in C would be quite natural (where we actually have
pointers):

	while (*s && *s == '\n')
            s++;

but the above elisp is quite nasty.

> In fact, the code would probably be simpler if you
> immediately appended the string to the process buffer like a normal
> process-filter and then peeled things away using buffer-oriented
> regexp functions like looking-at.  Elisp is a lot better at
> manipulating buffers than it is at manipulating strings.

I spent a bit of time trying this. Using looking-at is definitely better
than string-match since we can then use things like (match-string 1)
rather than (match-string 1 string). And getting rid of the "line"
variable means that all of the ugly expressions like the one I showed
above went away.

The approach I tried was to use a temporary buffer for the unparsed data
and the process buffer for the resulting parsed data. The code got a bit
awkward as I kept having to jump back and for between (with-temp-buffer)
and (with-current-buffer buffer)---particularly due to the buffer-local
variable to hold the trailing data from the past run.

A better approach might be to use a single buffer, leave the unparse
data at the end, and just make it hidden.

But I'll leave this alone for now since fighting elisp has left me
annoyed. If anyone wants to clean up my hideous elisp here, then that
would be fine with me.

-Carl

-- 
carl.d.worth@intel.com