On 2008/07/11 10:46 +0200, Patrice Dumas wrote: > I think it is worth mentionning the weaknesses of texi2html. I think > that the most problematic one is the home made parser. It is not that > complicated for the 2 first passes. But in the last pass, it gets very > complicated. There is a stack with @-commands with braces and 'formats' > (@table, @itemize, @cartouche....) and, in parallel a state which holds > document-wide informations, including some stacks, to know which format > of each type is on the top for complicated imbrications. In the stack > there are fake formats that are not really formats from a texinfo > perspective but are important for nesting, like a definition body, a > cell and lrow in a multitable. There are exceptions everywhere with > complicated conditions on the state. Another complication is that > formatting of some things may lead to nested formatting, like, for > example, a footnote text in normal text. > > I don't know if it is because of a poor design of the parser (which was > never designed, and never really redesigned when new texinfo language > rules appeared) or because texinfo is intrinsically complicated, but > it is quite messy and I am often lost in it.
In case it wasn't clear from what I previously wrote, note that I haven't read texi2html code; I only skimmed a little through it, and I might understand that you are lost in it, when you have very long functions (1442 lines for rearrange_elements()). Maybe you have designed this purposely to save function calls, but I would be lost in this too if I had to maintain it: such huge control-flow blocks are hard to read. I'd like to explain in a few words the (still incomplete) design of my hypothetical project; if it's not implemented from scratch, it might help give ideas for improving portions of texi2html. However, it's late for me this evening |-), I'll come back with it within one week. Cheers, John
