[SomeCallMeTim]

My gut reaction is that I don't want to be creating a table of contents list of sections by hand.

I feel it's a design error to require the sections be listed at the top and named below. If I want to change a name below, then I have to remember to make the identical change above.

Unless there's something obvious I'm missing about how literate programming works, it seems like a "generate table of contents" macro would be vastly superior to having to maintain it by hand.

[cdosborn]

Its no different then defining a function and calling it later (and proceeding to change the function name in several places). There are tools that generate a TOC based on markdown headers. I'm not sure I understand. There is also no mandated order, of where macros are defined except in the << * >>= which specifies the root to eventually expand the macros into a code file.

[daveloyall]

NB: I've only read the README.md.

My first thought was to use emacs org-mode to manage these .lit files.

My second thought was to consider: do I want name.lang.org.lit or name.lang.lit.org? ... I am leaning towards the latter.

[macmac]

If you are using org-mode you should consider org-babel which does all you need for litrate programming and more.

[daveloyall]

I've used org-babel, but I'm still interested in Lit. The 'watch directory' feature interests me, as does the 'proper and complete' aura of Haskell.

I'd previously played around with getting org to do stuff "on commit", via git hooks, but I didn't make much progress (and given the environment I was committing from, I was sure that I was going about it backwards anyway).

Org still doesn't have a universal character escape mechanism!