Repository navigation
Public API follow-up: quote content, fence helpers, answers reader, block lines #93
Description
Summary
#90 made almost everything legaldown-render needs public. After adopting 0.3.0, the renderer still imports these from private modules (its validator_bridge.py):
| Import | Used for |
|---|---|
legaldown.parser.quote_content, MAX_QUOTE_DEPTH |
A block quote's content blocks, as the validator reads them. Block holds a quote only as text. |
legaldown.markdown.FENCE_OPEN_RE, closes_fence, dedent, indent_width |
A code block's content and info string, read the way the parser reads a fence. |
legaldown.cli._read_answers |
Reading an answers file (YAML/JSON) for assemble(), with the same errors as legaldown assemble. |
One more gap: a block's line. Since #85, the validator's diagnostics name their line. The renderer's own diagnostics (render-ref-ambiguous, ref-not-enumerated, render-not-processed) can't, because the SourceMap/Locator that finds a block's line is private. PlacedMarker.line covers markers only.
Proposal
- Export
quote_contentandMAX_QUOTE_DEPTHfromlegaldown. Better still, give a quote block its content blocks in the model, the way Keep nested list structure in the model and when serializing (#16) #61 did for list items. - Expose a code block's info string and content, either as
Blockfields or through one public helper, so a consumer needs no fence helpers. - Export a public
read_answers(path). - Give a public way to find the line of a block or a list item in a parsed document. For example:
ValidationResult.line_of(section, block, item=None), orlineonBlock/ListItem.
The drafting-note content (#88) is related; the rest of U3 is done.
Found while adopting 0.3.0 in legaldown-render.
Activity
Model answers for tools: quote_blocks, drafting_note_blocks, code_con…
Tooling API: wire stages 2 and 3 into legaldown.syntax and the README
0.4.0 Tooling API: legaldown.grammar, legaldown.syntax, and the answe…