|
|
||
|---|---|---|
| .. | ||
| testdata | ||
| analytics.go | ||
| analytics_test.go | ||
| BUILD | ||
| example_syncer.go | ||
| example_syncer_test.go | ||
| headers.go | ||
| headers_test.go | ||
| kubectl_dash_f.go | ||
| kubectl_dash_f_test.go | ||
| links.go | ||
| links_test.go | ||
| mungedocs.go | ||
| preformatted.go | ||
| preformatted_test.go | ||
| README.md | ||
| toc.go | ||
| toc_test.go | ||
| util.go | ||
| util_test.go | ||
| whitespace.go | ||
| whitespace_test.go | ||
Documentation Mungers
Basically this is like lint/gofmt for md docs.
It basically does the following:
- iterate over all files in the given doc root.
- for each file split it into a slice (mungeLines) of lines (mungeLine)
- a mungeline has metadata about each line typically determined by a 'fast' regex.
- metadata contains things like 'is inside a preformatted block'
- contains a markdown header
- has a link to another file
- etc..
- if you have a really slow regex with a lot of backtracking you might want to write a fast one to limit how often you run the slow one.
- each munger is then called in turn
- they are given the mungeLines
- they create an entirely new set of mungeLines with their modifications
- the new set is returned
- the new set is then fed into the next munger.
- in the end we might commit the end mungeLines to the file or not (--verify)