Hi all, I hope that this isn't too out of left field, especially coming from a relative unknown. I do however think that this is a conceptual problem in the Parser class which ought to receive some attention eventually. You see, it seems to me that the Parser is in fact more Renderer than it is parser, and most of the options in ParserOptions are in fact Rendering options. I noticed this while working on a tag extension for events. My goal was to parse some wikitext to obtain an array of PHP objects of a class Event which cooresponds to a an "event" tag I've defined. Well, I can sort of pull this off by creating a special parser, and adding parser hook which builds the objects for each array and sticks them into a global. Of course to do this I need to initialize the parser with a ParserOptions object, and of course the parser goes on to render HTML which I don't actually want, since the goal is just to get the intermediate stage. It occurs to me that separating the Parse stage from the Render stage could have some other useful effects, like making it easier to add different renderers, and making it a bit easier to start on the Parser rationalizations that people have been talking about. Of course any such separation will mean having to specify at least some of the parser and renderer behaviour, but maybe not all. At any rate it should make it easier to do so. So my question is this: does separating the two functions seem like a worthwhile task to anybody else here? Thanks for you time, -mark -- -- ================================================================= -- mark at geekhive dot net --