Been thinking about this a bit further. To keep things simpler…
Maybe the parser doesn’t even need to know about commonmark headers.
Instead it would just look for the block level consistent attribute {} directly associated with a table.
If it doesn’t exist then it’s given a placeholder id table<num> internally. Can’t remember if {} goes above or under a block however.
This would also be handy for a psv utilities to locate and replace tables with a new regenerated table (e.g. a github action to sync readme values with sourcecode)
{id=example_table}
| "test 1" | "test 2" | "test 3" |
| ------- | ------- | ------- |
| "A1" | "A2" | "A3" |
| "B1" | "B2" | "B3" |
| 1 | 2 | -3 |
| true | false | null |
| C1 | C2 | C3 |
{id=example_table}
| “test 1” | “test 2” | “test 3” |
|---|---|---|
| “A1” | “A2” | “A3” |
| “B1” | “B2” | “B3” |
| 1 | 2 | -3 |
| true | false | null |
| C1 | C2 | C3 |
Anyway, I’ve also moved the project to it’s own site https://psv-format.github.io/ so other can more easily contribute to this concept psv-format · GitHub .