[yoava]

Problem

Editing a cell in a table code block can fail to save, or save over the wrong part of the note. TableSyncService.syncCodeBlock builds a regular expression from the block's whole source and runs content.replace with it:

1. Large tables never save. For a table of about 40 KB, V8 throws Regular expression too large. VaultService.modifyFile catches the error, so the cell shows the new value while the file stays unchanged, with no message.
2. Editing a later block deletes earlier ones. The pattern starts at the first table fence in the note, so editing the second block replaces everything from the first block down to the second, including the first table and the text between them.
3. $ in cell text corrupts the note. The replacement is a string, so $`, $& and $' expand. A cell containing `$` (a dollar sign in inline code) ends up holding all the text above the table.
4. CRLF notes get mixed line endings, and the fallback overwrites the first block whenever the source doesn't match.

All four reproduce in Obsidian 1.12 on Linux.

Fix

• Fences are found by scanning lines: backtick and tilde fences, closing fences at least as long as the opener, blocks nested in other fences skipped, list indentation and callout > prefixes stripped for matching and put back on write.
• The target block is the one whose body matches the rendered source. Among identical tables, the line from ctx.getSectionInfo(el) decides, and a block at that line that no longer matches is never swapped for another.
• Only the body lines are replaced, by splicing (no replacement patterns), and each line keeps its line ending.
• syncCodeBlock returns whether it wrote. When no single block matches, nothing is written and a Notice appears. The view advances its expected source only after a successful save, and one view's saves run in order, so a quick second edit doesn't race the first.

Behavior change: the opening fence is kept, so tablebase and notion-table blocks are no longer renamed to table.

Known limits: a fence on the same line as a list marker (- ```table) is not recognized, so that save is skipped with a notice. Indented code is not told apart from list continuation.

Tests

npx vitest run: 350 passed. New cases in tests/table-sync-service.test.ts cover a large table, multiple blocks, $ patterns, no match, identical tables with and without a line hint, fences nested in other code blocks, tilde and longer fences, list and callout prefixes, and CRLF. Run against the old service, 10 of its 13 tests fail. The controller tests cover the return value and save ordering.

Checked manually in Obsidian with the built plugin: a 40 KB table saves two edits in a row with only the edited rows changed, editing the second block leaves the first untouched, and a cell with `$` saves literally.

🤖 Generated with Claude Code

[a269ch]

Hi @yoava! Thank you again for your contribution to TableBase. I really appreciate the work on both PRs and am very glad that you are helping make the project more reliable.

Before merging, please bring both PR #7 and PR #9 in line with the project guidelines:

• each PR should address one focused task;
• each PR should contain exactly one commit after squashing;
• commit messages should follow the format described in CONTRIBUTING.md;
• the PR description should be concise and follow the pull request template;
• include the results of npm test and npm run build;
• remove unrelated changes, generated files, and unnecessary comments.

Please also see the related note in PR #7. Thank you again for helping improve TableBase!

[a269ch]

Thank you for improving code block synchronization. Could we preserve the existing line ending for each replaced body line here? Using the opening fence line ending for every new line can normalize a body that contains mixed LF and CRLF endings, creating unrelated changes and noisy diffs. A regression test with mixed line endings would make the intended behavior explicit.