sgml.g and tree structure for nested tags

Tue Aug 10 05:49:38 UTC 2010

The formatters (little buggy, and much simpler) currently works similar there 
is no concept of a tree. It was one of my original ideas to simply have a 
list, but after some uneducated thought, I figured it would simplify the 
context builder. But the builders and the .g became such a complex mess that I 
see this approach actually only simplifying it.

Sorry I do not have any time for the next 3 months, I am writing exams and 
lots of work.

End Nov and Dec I will have time again for some hobby code'n.

Cheers

On Sunday 08 August 2010 16:46:58 Milian Wolff wrote:
> hey Ruan,
> 
> I'm thinking about simplifying sgml.g by making it generate a list instead
> of a tree. I remember that you have asked us/me back then how to create
> the tree and put much work into it, but when I actually work with it now,
> I don't think a tree is really that good here.
> 
> Html/Xml is pretty easy after all, and the parser should just give us nodes
> with stuff like
> 
> - <!doctype
> - <?xml ?>
> - <opentag> (attributes, maybe empty)
> - </closetag>
> - CDATA
> - TEXT
> 
> that's basically it. The rest should go into the ContextBuilder, i.d. open
> a context inside <opentag>, close it on </closetag>.
> 
> When doing so, we can also report proper errors when tags are incorrectly
> nested, or closed at the wrong point (or not at all).
> 
> Another point, which actually sparked my idea, is this:
> 
> <html>
> <?php /* ... */ ?>
> </html>
> 
> I personally would see this as HTML embedded in PHP (as the latter is the
> preprocessor). The current multilang approach hands "<html>\n" and
> "\n</html>" as two parts over to the XML language plugin, hence the AST
> cannot be built in the correct way currently. When it's simply generating
> a list of stuff and the context builder would cope with the rest as
> proposed above, it should work like a charm.
> 
> Bye