fix(tostring): account for tag decoration in table column width#517
Merged
Conversation
A `#`-prefixed token in a table cell (`#foo`, `#bug`, `OXY2DEV#51`) is parsed as an Obsidian-style tag. The tag renderer conceals the leading `#` and injects padding_left/padding_right (and, if configured, corner/icon) as inline virtual text, so the rendered cell is wider than its raw text. The table column-width calculation, however, runs through renderers/markdown/tostring.lua, which had no tag handler: it measured the raw text (`#foo` = 4 columns) and was blind to the conceal + padding. The mismatch drifted the cell's right border (about +1 per tag cell with the default padding). This is not limited to numeric refs -- `#foo` drifts exactly like `OXY2DEV#51`. The cause is the missing tag-width accounting in tostring, not whether the tag body is numeric (the separate question of whether purely-numeric `OXY2DEV#123` should be a tag at all, per Obsidian, is orthogonal and left unchanged). Fix: give tostring a tag handler that mirrors the renderer -- strip the `#`, resolve the tag config via utils.match, and emit corner_left + padding_left + icon + label + padding_right + corner_right -- plus an lpeg tag pattern guarded like the parser (start/after-whitespace, not an internal-link `#^section`). The computed width now matches what is drawn. Renames the fixture to test/table_ref_tag_drift.md and generalizes it: non-numeric tags drift too, and the repro documents the tostring root cause.
ImmanuelHaffner
force-pushed
the
fix-tostring-tag-width
branch
from
fcb71a1 to
62de491
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A
#-prefixed token in a table cell (#foo,#bug,#51) is parsed as an Obsidian-style tag. The tag renderer conceals the leading#and injects padding_left/padding_right (and, if configured, corner/icon) as inline virtual text, so the rendered cell is wider than its raw text. The table column-width calculation, however, runs through renderers/markdown/tostring.lua, which had no tag handler: it measured the raw text (#foo= 4 columns) and was blind to the conceal + padding. The mismatch drifted the cell's right border (about +1 per tag cell with the default padding).This is not limited to numeric refs --
#foodrifts exactly like#51. The cause is the missing tag-width accounting in tostring, not whether the tag body is numeric (the separate question of whether purely-numeric#123should be a tag at all, per Obsidian, is orthogonal and left unchanged).Fix: give tostring a tag handler that mirrors the renderer -- strip the
#, resolve the tag config via utils.match, and emit corner_left + padding_left + icon + label + padding_right + corner_right -- plus an lpeg tag pattern guarded like the parser (start/after-whitespace, not an internal-link#^section). The computed width now matches what is drawn.