Bug Description
A [[wikilink]] inside an inline code span (backticks) is parsed as a relation. CommonMark treats code spans as literal text, and Basic Memory already respects fenced code blocks (a wikilink inside ``` does not mint an edge), but inline spans are not honoured — so prose that quotes a relation line as an example creates a real edge to the quoted target.
Practical impact: retiring a hub note. Two real part_of [[Daily log]] edges were removed, the inbound count would not drop to zero, and the survivor turned out to be a sentence in another note that documented the template line inside backticks purely as an example. The quoted mention kept the retired hub "alive" in the graph, and any orphan/hub-integrity metric built on relation rows sees it as a live link.
Steps To Reproduce
- Install version
0.23.2 (also reproduced on 0.22.1).
- Write a note whose only wikilinks are inside code:
bm tool write-note --title "Codespan Probe" --folder inbox --project main --content '# Codespan Probe
The template line is documented as `- part_of [[Codespan Inline Target]]` and must not create an edge.
```markdown
- relates_to [[Codespan Fenced Target]]
- [fact] only prose and code here'
3. Inspect the relations minted for that note:
```sql
SELECT r.relation_type, r.to_name, r.to_id
FROM relation r JOIN entity e ON e.id = r.from_id
WHERE e.title = 'Codespan Probe';
Expected Behavior
No relation rows. Both targets are inside code — one inline span, one fenced block — and neither is a link in the CommonMark sense.
Actual Behavior
relation_type|to_name|to_id
links_to|Codespan Inline Target|
The fenced-block link is correctly ignored; the inline-span link becomes a links_to relation (unresolved here only because the target does not exist — with an existing target it resolves to a real to_id, which is the hub-retirement case above).
Environment
- OS: macOS 27.0 (Apple Silicon)
- Python version: 3.12.13
- Basic Memory version: 0.23.2 (same on 0.22.1)
- Installation method:
uv tool install basic-memory==0.23.2 --prerelease=allow
- SQLite backend, local mode
Possible Solution
Mask inline code spans (`...`, including double-backtick spans) before the wikilink / relation regexes run, the same way fenced blocks are already skipped. The parser only needs to treat backtick spans as opaque text; nothing else about link extraction changes.
Bug Description
A
[[wikilink]]inside an inline code span (backticks) is parsed as a relation. CommonMark treats code spans as literal text, and Basic Memory already respects fenced code blocks (a wikilink inside```does not mint an edge), but inline spans are not honoured — so prose that quotes a relation line as an example creates a real edge to the quoted target.Practical impact: retiring a hub note. Two real
part_of [[Daily log]]edges were removed, the inbound count would not drop to zero, and the survivor turned out to be a sentence in another note that documented the template line inside backticks purely as an example. The quoted mention kept the retired hub "alive" in the graph, and any orphan/hub-integrity metric built onrelationrows sees it as a live link.Steps To Reproduce
0.23.2(also reproduced on0.22.1).Expected Behavior
No relation rows. Both targets are inside code — one inline span, one fenced block — and neither is a link in the CommonMark sense.
Actual Behavior
The fenced-block link is correctly ignored; the inline-span link becomes a
links_torelation (unresolved here only because the target does not exist — with an existing target it resolves to a realto_id, which is the hub-retirement case above).Environment
uv tool install basic-memory==0.23.2 --prerelease=allowPossible Solution
Mask inline code spans (
`...`, including double-backtick spans) before the wikilink / relation regexes run, the same way fenced blocks are already skipped. The parser only needs to treat backtick spans as opaque text; nothing else about link extraction changes.