Type: feature decision — not tech debt. The current behaviour is deliberate, not an accumulated shortcut. This issue records an open product decision about source-map precision; it should not be picked up as cleanup or janitor work. It is actionable only as a scoped feature, and only under the condition in "When this is worth doing" below.
Current behaviour (by design)
crates/mds-core/src/evaluator.rs:228-241 emits exactly one source-map segment per Node::Text. A static text run spanning multiple lines therefore produces a single segment anchored at the run's start, so downstream consumers resolve every interior line of that run back to the run's first line.
This is a design choice, not an oversight: one segment per node keeps segment count proportional to AST nodes rather than to output lines.
The decision
Should interior lines of a multi-line static run receive their own segments?
The trade-off is segment count against editor precision:
- For finer granularity — an editor mapping a position in compiled output back to source lands on the correct source line inside a multi-line run, instead of always on the run's first line.
- Against — segment count then grows with output lines rather than AST nodes. The ceiling is 1,000,000 segments (
MAX_SOURCEMAP_SEGMENTS, crates/mds-core/src/limits.rs:113); segments past the cap are silently dropped, yielding a partial map. A per-line scheme spends headroom that the current scheme leaves effectively untouched.
When this is worth doing
If editor integration becomes a priority — specifically #65 (VS Code extension), #66 (Tree-sitter grammar), #67 (LSP server).
Interior-line precision only pays for itself when something is actively consuming the map for cursor mapping. Absent a consumer, the coarser mapping is adequate and strictly cheaper. If any of #65/#66/#67 move forward, revisit this as part of that work rather than in isolation.
Until then this stays open as a recorded decision, not as pending work.
Originally surfaced during the 2026-07-17 dogfooding campaign alongside PR #196, and deliberately not implemented there.
Current behaviour (by design)
crates/mds-core/src/evaluator.rs:228-241emits exactly one source-map segment perNode::Text. A static text run spanning multiple lines therefore produces a single segment anchored at the run's start, so downstream consumers resolve every interior line of that run back to the run's first line.This is a design choice, not an oversight: one segment per node keeps segment count proportional to AST nodes rather than to output lines.
The decision
Should interior lines of a multi-line static run receive their own segments?
The trade-off is segment count against editor precision:
MAX_SOURCEMAP_SEGMENTS,crates/mds-core/src/limits.rs:113); segments past the cap are silently dropped, yielding a partial map. A per-line scheme spends headroom that the current scheme leaves effectively untouched.When this is worth doing
If editor integration becomes a priority — specifically #65 (VS Code extension), #66 (Tree-sitter grammar), #67 (LSP server).
Interior-line precision only pays for itself when something is actively consuming the map for cursor mapping. Absent a consumer, the coarser mapping is adequate and strictly cheaper. If any of #65/#66/#67 move forward, revisit this as part of that work rather than in isolation.
Until then this stays open as a recorded decision, not as pending work.
Originally surfaced during the 2026-07-17 dogfooding campaign alongside PR #196, and deliberately not implemented there.