For cases where event schema specify `patternProperties` it would be nice
to give that pattern a "human-readable" form rather than a raw regex. This
is now supported by specifying `x-pattern` in the value part of the specified
pattern e.g. `patternProperties:{ "^.*":{ x-pattern: "$THING", ... } }`
Templating had limited record type descriptions limited to value primitives
e.g. `{string: integer}`. It now supports inspecting the values recursively
if the value is `object`.
Updated `m.receipt` to take both these points into account to make it read
better. Tweak receipt module text.
Ignore .git directory as that shouldn't affect spec generation. Also, when
we receive writes from the OS, wait a bit before re-generating the spec to
clump together multiple writes rather than re-generating one after another
and waiting for no more writes before serving the request.
The CSS for `nature.css` was such that it was preventing `p` tags from
having sufficient vertical whitespace. This meant that you couldn't insert
any kind of spacing between lengthy sections (they just appeared as new lines).
This PR fixes this so you can actually have some whitespace between paragraphs.
As a result of this change, some parts of the spec appeared to have too much
whitespace. These were often sections which shouldn't have begun a new
paragraph anyway (e.g. a single sentence being an entire paragraph, `TODO`
blocks resulting in new paragraphs). This PR fixes the most offending areas
where we shouldn't have been inserting new paragraphs.
fields including a '.' can be included in a filter.
I considered replacing '.' with '/'. Since '/' was less likely to appear
in event field names. However if we used '\' to escape a literal '/' we
risk confusing it with the JSON escape '\/'.
Kegsay