mirror of https://github.com/k3s-io/k3s
1ce3081e55
If preformat lines are unbalanced, do not delete all the lines from there to end of file. That might be the only copy of edits made by the user. Do not print entire file contents for munge errors affecting entire file. |
||
|---|---|---|
| .. | ||
| testdata | ||
| README.md | ||
| analytics.go | ||
| analytics_test.go | ||
| 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 | ||
| toc.go | ||
| toc_test.go | ||
| unversioned_warning.go | ||
| unversioned_warning_test.go | ||
| util.go | ||
| util_test.go | ||
| whitespace.go | ||
| whitespace_test.go | ||
README.md
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 preformmatted 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)