Here we start with as specific algorithm that is not large but has already defied an attempt at refactoring. We'll abstract it to pseudo-code and then suggest markup keywords that are both a simple and powerful replacement. See Growing Regions as Hypertext
Here is what I'm thinking I should do: Add a keyword, DOT, to the Graphviz plugin that surplants the existing dot markup with dot from some other source. riot 
I will expand this with additional keywords to make a markup language roughly as complex as the Grep plugin which knows how to look for things in a site. I will make sure that one can say DOT LINEUP that will mean find a dotsource in the lineup. The Map plugin already does something like this.
I will also slightly generalize my 40 lines of Mehaffy specific code so as to find relevant links by various means, including "charmed" markdown. I think I could have this done by the weekend. For me the motivation is to have fast diagnostic tools to help Michael succeed with his Growing Regions collaboration.
The code understands something about how we format section and pattern pages. It maps the link structure of the patterns within one section. github
for each link on a section page draw a node tentatively colored 'bisque' if link exists in sitemap for each "charmed" paragraph for each link draw a node colored 'lightblue' or 'gray' draw arrow to or from the 'bisque' node else draw a fake 'gray' node draw two fake input nodes draw two fake output nodes
The current implementation does not treat links as Collaborative Link. More tight integration with core javascript might enable this fundamental improvement.
I hacked a version of this algorithm into the ebook extractor where "await fetch(slug)" turned into "e[slug]" where e is the extraction in progress. github
See Graphviz Markup Semantics derived from examples.
Markup will breadth-first traverse the tree represented by indentation. Lower case passed through to dot. HERE for current page. LINK for all links in this context that exist, ELSE when absent. WHEN charms items that match. NODE makes dot node. -> makes dot edge. FAKE makes a node of similar name.
strict digraph { node [shape=box style=filled fillcolor=lightgray] rankdir=LR "Design-Build Adaptation" [fillcolor=bisque] "Biophilic Urbanism" [fillcolor=lightblue] "Biophilic Urbanism" -> "Design-Build Adaptation" "Design-Build Adaptation" -> "Community Mockups" "Human-Scale Detail" [fillcolor=bisque] "Design-Build Adaptation" [fillcolor=bisque] "Design-Build Adaptation" -> "Human-Scale Detail" "Ornamental Construction" [fillcolor=lightblue] "Human-Scale Detail" -> "Ornamental Construction" "Complex Materials" [fillcolor=lightblue] "Human-Scale Detail" -> "Complex Materials" "Ornamental Construction" [fillcolor=bisque] "Human-Scale Detail" [fillcolor=bisque] "Human-Scale Detail" -> "Ornamental Construction" "Complex Materials" [fillcolor=bisque] "Biophilic Urbanism" [fillcolor=lightblue] "Biophilic Urbanism" -> "Complex Materials" "Community Mockup" [fillcolor=lightblue] "Complex Materials" -> "Community Mockup" }
DOT strict digraph rankdir=LR node [shape=box style=filled] HERE node [fillcolor=bisque] LINK HERE node [fillcolor=lightblue] WHERE /^When / LINK NODE -> HERE WHERE /^Then / LINK HERE -> NODE node [fillcolor=gray] ELSE FAKE NODE -> HERE FAKE NODE -> HERE FAKE HERE -> NODE FAKE HERE -> NODE
Here is a diagram based on charmed paragraphs in the lineup. We duplicate this showing lineup pages as bisque.
DOT digraph node [shape=box style=filled fillcolor=bisque] LINEUP HERE node [fillcolor=palegreen] WHERE graph LINK HERE -> NODE
See Thompson's Anchors Visualized for a more challenging test case based on whole site analysis and ad-hoc selections based on age and count.
SITE retrieves every page. TALLY counts link frequency. COUNT selects specific frequency. DAYS selects specific age. INLINK is inbound version of LINK.
DOT digraph node [shape=box style=filled fillcolor=gold] rankdir=LR SITE TALLY LINK WHEN COUNT 6-999 NODE node [fillcolor=lightblue] HERE -> LINK WHEN DAYS 0-7 node [fillcolor=palegreen] INLINK -> HERE
.
The <graphviz-viewer> is just slow enough that one can read past where the diagrams will eventually go. So I have emit render a loading message but that is discarded quickly, probably by bind when it inserts the custom tag.
I wonder if there is a better place than emit to display this message?
.
I fiddled with eval for some time before I got serious about writing a breadth-first eval. Compare the parse and eval order for this test program.
DOT a node [shape=box style=filled fillcolor=gold] ZERO b ONE c node [fillcolor=palegreen] TWO d ONE e node [fillcolor=lightblue] TWO f THREE g ONE h ZERO i ZERO j node [shape=diamond] ZERO k ZERO l
| parse | eval |
|---|---|
DOT a [shape=box] ZERO b ONE c [fillcolor=palegreen] TWO d ONE e [fillcolor=lightblue] TWO f THREE g ONE h ZERO i ZERO j [shape=diamond] ZERO k ZERO l | DOT a [shape=box] ZERO b ZERO i ZERO j [shape=diamond] ZERO k ZERO l ONE c ONE e [fillcolor=lightblue] ONE h [fillcolor=palegreen] TWO d TWO f THREE g |
wiki-plugin-graphviz
DOT digraph rankdir=LR node [shape=box style=filled fillcolor=palegreen] HERE LINKS HERE -> NODE HERE LINKS HERE -> NODE
It's published, installed and in use here. We'll be learning lots about what we could have and now should be doing. See Dynamic Diagrams in Use