Repository navigation
Conversation
Cells lost inline code: the renderer flattens a code span to its text, and the cell parser only knew links, so a note's `code` showed as plain text and an edited cell wrote it back without backticks. The parser now reads CommonMark code spans (a link that starts first keeps them in its label), the source cell is preferred because its flattened form matches, and sort, filter, type inference and Kanban grouping read the flattened text. Code renders as a styled span rather than a code element, so plugins that act on inline code (Dataview queries, Meta Bind inputs) never run on cell text, as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Hi @yoava! Thank you very much for contributing to TableBase and for improving inline code rendering in table cells. I am very glad that you decided to help make the project better. Your contribution is greatly appreciated. I will leave the detailed contribution-format requirements in your other PR so we do not duplicate the same information here. |
| const rawHeader = table.headers[c] || ""; | ||
| const columnCells = table.rows.map((r) => r.cells[c] || ""); | ||
| // Types are read from the text a cell shows, so "`42`" is a number. | ||
| const columnCells = table.rows.map((r) => stripCodeSpans(r.cells[c] || "")); |
There was a problem hiding this comment.
Thank you for the inline code work. Could we also normalize the value used by the type-specific renderers? This line strips code spans for type inference, but checkbox/date/select/multi-select rendering still receives the original raw value. For example, `[x]`, `2026-01-01`, or `Done` can be classified correctly while isCellChecked, date parsing, or tag parsing still sees the backticks.
Please consider using the normalized value for display parsing while retaining the original Markdown value for editing and persistence. Regression tests for these typed columns would help protect this behavior.
fc93874 to
9542798
Compare
Problem
Inline code in a table cell is lost:
`code`as<code>, and the cell'stextContentdrops the backticks. The cell parser only recognizes links, so the code shows as plain text.```tableblocks: cells come from the raw Markdown, so the backticks show literally.Fix
link-renderer.tsparses CommonMark code spans (backtick runs of matching length, escaped backticks, one space stripped from each side, line endings as spaces). A link that starts first keeps any code span inside its label.toPlainTextflattens code to its text, soreconcileRowsmatches the source cell and keeps its backticks.`Done`groups withDoneand`42`still counts as a number.<span class="ms-cell-code">, styled with Obsidian's inline-code variables.Open question:
spanvscodeThe grid is built inside a markdown post processor, so post processors that run later (Dataview at order 100, for example) process its elements. A real
<code>would let Dataview inline queries (= ...,$= ...) and Meta Bind inputs run on cell text. Before this change they never ran, because the code was lost. The span keeps that behavior and looks the same. If you'd rather match native tables, switching to<code>is a one-line change inrenderTextWithLinks.Tests
npx vitest run: 348 passed. New cases cover code-span parsing, links with code in the label,stripCodeSpans, source reconciliation in the post processor, and code-aware sort and filter.🤖 Generated with Claude Code