Exactly. What I meant was that I never understood why AsciiDoc Python was implemented that way. It imposes many constraints, such as not being able to produce a TOC or validate cross references. (Of course, that's knowledge gained in hindsight, so I don't want to be overly critical of the choices made at the time).
-Dan On Fri, Feb 12, 2016 at 9:54 PM, Keith Packard <[email protected]> wrote: > > > On Friday, February 12, 2016 at 8:43:58 PM UTC-8, Dan Allen wrote: >> >> I've never understood why the TOC was done in JavaScript, which is why I >> reified it in Asciidoctor. >> > > It's pretty obvious when you look at the code -- the xhtml11 backend for > asciidoc operates almost as a stream processor. The only state it keeps > while processing the source file is a stack of section closing elements. > > Adding toc generation required saving the full output and inserting the > TOC in a post-processing step. > > -- > You received this message because you are subscribed to the Google Groups > "asciidoc" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/asciidoc. > For more options, visit https://groups.google.com/d/optout. > -- Dan Allen | @mojavelinux | http://google.com/profiles/dan.j.allen -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/asciidoc. For more options, visit https://groups.google.com/d/optout.
