Skip to content

Refine struct and block id interaction - #82

Merged
hon-gyu merged 4 commits into
mainfrom
hy/refine-keyed-and-block-id-interaction
Jul 28, 2026
Merged

Refine struct and block id interaction#82
hon-gyu merged 4 commits into
mainfrom
hy/refine-keyed-and-block-id-interaction

Conversation

@hon-gyu

@hon-gyu hon-gyu commented Jul 28, 2026

Copy link
Copy Markdown
Owner
  • spec/struct: define the block-id interaction
  • struct: pin the keyed/block-id interaction
  • vault: make a keyed node's block id reachable
  • bump oymarkit

hon-gyu added 4 commits July 28, 2026 21:29
A value segment consisting of nothing but a block-id marker is an empty
value: the marker is consumed as the node's identifier rather than
becoming its value, so the node keys as if a bare ":" had been written
and goes on to claim the following content -- a YAML-style anchor naming
the node and its subtree.

The marker's two effects deliberately land on different nodes: it is
consumed from the innermost value of a colon chain, while the identifier
it yields names the outermost node (the block the paragraph became).

Also generalise Rule 2 from list items to keyed nodes, and state that a
trailing blank line inside a list item is loose-list layout rather than
a claimable body.
Two expect tests over one case list: the tree shape each input produces,
and its CommonMark re-render. The second is the content-invisibility
check -- an id-only marker belongs to no block in the keyed tree, so it
exists only on a meta channel and [Struct.unkey] has to put it back.

Three roundtrip rows are pinned as not byte-identical; each reproduces
without any marker present, so none is specific to this change. They are
called out above the test.
The id was attached to Ext_keyed but every consumer matched
Block.Paragraph only, so it was write-only: invisible to the vault index,
to link resolution and to the rendered HTML.

- Index.extract_block_ids records keyed nodes, folding the body
  explicitly since Folder.ret suppresses the default traversal.
- Extract.get_block_by_caret_id returns the keyed node itself, so a
  [#^id] reference denotes the label together with everything the key
  claimed -- an anchor for a whole subtree, which is the point of it.
- The keyed <div> carries id="^x", matching the paragraph form.

Resolution reads Index.extract_block_ids, so the embed tests cover the
index fix too: without it the reference would not resolve at all.
@hon-gyu
hon-gyu merged commit 04e6d3c into main Jul 28, 2026
0 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant