(no subject)
Apr. 25th, 2002 10:23 ambook("Animals I Have Seen") / chapter("Monkeys") / section("Chromatic Monkeys") / section("Purple Monkeys") / para
(It would get the title information from the appropriate element's <title> child element. A generic XML editor would not know do to this. This is one of the many reasons I want a DocBook-specific editior.)
The puzzle involved how to transform given information about the cursor's current position within the text widget into information about where in the XML structure it is. One can do this in a number of dirty, hacky ways, but all these ways take amounts of time directly proportional to the size of the document, so don't make for very good solutions.
I had to either override the Cocoa text widget at low levels so that it contained not a single string but some freak-out structure of my own design, or keep a tree of separate memory structures that matched the document's XML structure, which would be able to return one of its nodes in answer to a query based on current cursor position. Both are pretty hard, but the latter seemed easier.
After spending a few evenings coming up with solutions which would have technically worked but would have again involved machine-work proportional to document size, I think I now have a viable solution. Strange that I came upon it as a passtime while my Precious is still in the hospital. (Where it is still listed as "Awaiting Part", sigh.) I did it on paper, over several mazey pages of pseudocode and doodled scratch-work with circles and arrows and a paragraph on the back of each one, and in thinking about it I wonder if all the best programming ideas I've had happened while I had a pen in my hand, rather than a keyboard under my fingers.
Yeah, see, it makes sense: with pen and paper, you can realize your thoughts in two dimensions. When taking notes in a text editor, you have only one dimension, going forward or back along the string of text you have. Wow. Have I ever thought of it that way? Maybe not.