OK, so I lied. I'll write about code visualisation when I can be bothered. Besides, when I read my previous diary entry, I sounded like Steve Job's pet gerbil on speed. I'm writing code, not marketing!

Speaking of Apple... I've been looking at those liquid gel buttons for ages, admiring just how beautiful they are. I'd love to have that under Linux, perhaps with some modelling of ink-drops, so this delicious red mist can swirl around inside a transluent blue button. Moving a window could shake the buttons inside, changing the swirl patterns. I'd buy another CPU to handle that sort of user interface! :)

I've written most of the parser for csed/cgrep. The parser is able to comprehend and step through itself, extract comments, functions, strings and variables (basic types only). Next step is to add in structs and typedefs so the parser can understand more complicated variable declarations. I'll know I've done a good job here when it understands Gtk+ types.

However, I've run into the same old brick wall. I've written the parser two ways and I don't know which one to keep.

The first is to have a central routine which feeds data character by character into state machines. This has the advantage of allowing me to feed in data from anywhere, so it would be easy to hook an editor into it.

The second method allows the state machines to retrieve information themselves, using callbacks to inform the main routines of any changes. This has the advantage of being able to embed any kind of callback, not just state changes, but would require an editor to have knowledge of the parser.

I could just flip a coin and pick one at random, but it would be a lot of work to back out one method and insert the other method if I discover my chosen method won't expand far enough to be capable of doing what I want. The hard part is that I want this to be totally compatible with existing code and methods. Eg, this ain't gonna be another IDE, but it should be easy to integrate into existing environments.

I'm ignoring this problem for the time being and have started writing a multi-state pattern matcher for the variable namespaces. When that's mostly complete, I'll look into how the parser and namespace engines can best hook into each other. I'm not using lex/yacc or any external libraries at this point, just ANSI C, so I have more leeway in choosing how to fit things together.

On the bright side, it should be pretty easy to change things around once I have these things working, so maybe I shouldn't sweat so much.