Weaving

Part: Work in progress

Chapter: Weaving

Language: TypeScript

Raw source

Weaving

Weave is tangle's mirror. Tangle drops a loom's prose, inlines every ::[…] anchor, orders the sections by composition, and writes source files. Weave keeps the prose, turns each anchor into a link, holds the sections in the order they were written, and writes data. The prose that tangle throws away is what weave is for.

loom weave <corpus> reads a corpus and writes one file: a WovenCorpus, the corpus as data. It is not a website and not HTML. It is every chapter as a page, its prose and its code side by side, every anchor a link to the section it names — all of it plain data a consumer renders however it likes.

The projection

At the centre is one pure pass. WeaveBuilder reads the parsed corpus and returns a WovenCorpus — a page for each chapter, a navigation tree of the corpus's parts and chapters, and the links between them. It mirrors the product pass. Where the product pass composes each document into the code it hides, the weave pass projects the corpus into the literate document a reader browses. Like every pass it is total and knows nothing of how the result is shown.

Weave renders the parsed document, not the product. A woven page holds each section's prose and each section's code as the author wrote them, in reading order, with every ::[…] still a reference — now a link the reader follows, the way Knuth's weave cross-references a section rather than pasting it in. The composed form is tangle's; the literate form is weave's.

The projection reuses what the corpus already holds. The parse gives each chapter's sections in document order. The corpus graph — resolveAnchor and the title index — gives each link its target. So the pass is one more reader of the same structure the editor navigates by.

Data, not a site

A WovenCorpus is data: what a corpus contains, not how a site around it looks. It carries no chrome. No top menu lives in it, because a menu spans several corpora that no single corpus knows about. No theme and no chosen sidebar live in it either, because those belong to whoever renders it. loom weave writes the data; the presentation is free.

So weave runs per corpus, once for each. A project with a corpus of guides and a corpus of source weaves two files, and a consumer mounts them side by side under whatever navigation it wants. The Loom Website in Part X is one such consumer, and not a privileged one — the same JSON serves any reader built against the schema.

The source anchor

Weave keeps every block tied to the loom it came from. Each block records a source anchor: the chapter and the section it was written under. A consumer carries the anchor onto the element it draws, so a reader who points at the rendered page points at the loom section behind it — the spec, not the HTML.

That tie is what lets a person annotate looms as specs. Loom Design reads the source anchor to pin a note to the source rather than to a brittle element selector, so a re-weave and the edits around it leave the pin where it belongs. The woven page and the loom it came from meet in one place.

Loom