Conversation
Table rows were mapped to source lines by sniffing line content: any line whose cells are all dashes was treated as the delimiter row and dropped from the row index. A data row written `| - | - |` matched too, shifting every subsequent index. Two silent failures followed. The row after an all-dash row lost its mapping, so `rememberCellSourceEdit` returned early and edits in it were discarded; the all-dash row meanwhile carried the following row's index, so committing it rewrote that source line and destroyed its content. `deleteRow`, `moveRow`, range paste and the selection Delete handler shared the same misindexing. Rows already carry their own absolute offsets — `adaptTable` records `position(c.from, c.to)` for every TableHeader and TableRow — and the widget already reads cell positions the same way. Resolve the line from the row's own position instead of guessing from content; the delimiter row is the one line no row claims. `addColumn` now treats only that line as the delimiter, falling back to the content predicate when it cannot be resolved, so a degenerate AST cannot make the command refuse to edit. `estimateTableHeight` still uses the content predicate; it affects height estimation only and is left for a follow-up. Co-Authored-By: Claude Code <noreply@anthropic.com>
The fix that resolved table rows to source lines via AST positions shipped with tests for the mapping itself and for `addColumn`, but the four other call sites it corrected had no coverage: `deleteRow`, `moveRow`, range paste and the selection Delete handler. All four resolve their lines through the same function, so a regression in it would have re-appeared silently. Each test drives the real interaction rather than calling internals: a row grip click plus Delete for `deleteRow`, a grip mousedown/mousemove/mouseup sequence for `moveRow`, and a cross-cell range selection for the paste and Delete paths. The paste case reaches the table through its input target provider, which is the path a real paste takes. Verified in both directions. Against the pre-fix source all four fail, with symptoms matching the bug report: Delete removes the wrong row, the drag is a silent no-op, and the paste lands on the wrong line. Against the fix all pass. Co-Authored-By: Claude Code <noreply@anthropic.com>
|
|
c19881230
changed the title
This branch has not been deployed
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.
Summary / 摘要
表格行改为按自身在文档中的位置定位源码行，不再靠匹配行内容| - | - |内容全是短横线的数据行不会再导致其后每一行的行号错位。
Motivation / 背景与动机
分隔行原本靠"这行内容是不是全是短横线"来判断，而内容全是短横线的数据行与它无从区分，于是被一并跳过，导致其后每一行都错位一位：后面那行拿不到行号，改动被丢弃；全横线行则拿到了后一行的行号，提交时把后一行覆盖掉。这四处调用点共用同一份错位数组。分隔行在解析结果里没有对应节点，因此行号只能按各行自身的位置来算 —— 这也是单元格早就在用的方式。
docs/ROADMAP.md): N/A — bug fixChanges / 变更内容
packages/core:新增两个函数按行自身位置算出行号，分隔行改为"没有任何一行认领的那一行"；原来五处扫内容的代码全部收敛到同一个函数。
packages/core:加列只给真正的分隔行补---`，定位不到时退回旧判断；拖拽换行序仍按当前源码算行号，因为传入的快照整行重写过。packages/plugin-*: N/Aapps/electron-demo: N/Aopenspec/: N/A — no public API change.Testing / 测试
pnpm testpasses / 全绿 —— 899 通过 / 10 失败；10 个失败均为预先存在且与本改动无关（见下方环境说明）pnpm build) / 受影响包构建通过 —— 退出码 0，14 个包全部通过packages/core/test/live-preview.test.tsgit diff --checkManual side-by-side check / 人工并排对比验证
旧版（修复前）表格输入进去的时候会出现四个问题：
x所在格子，改动会消失，表格里依然是x。| - | - |行并按 Delete 时，删除的是x|y那一行。| - | - |行里的内容时，x|y格子的内容变成修改后的值，而| - | - |行保持不变。经过修复：修改单个表格内容可以丝滑实现，拖拽换行功能成功运行，选中的删除项不会出现混淆。
本地环境说明： 本机
pnpm test为 899 通过 / 10 失败。这 10 个失败均为预先存在，集中在apps/electron-demo/test/plugin-host-broker.test.ts，报错为EPERM: operation not permitted, symlink—— Windows 在未开启开发者模式或提权时不允许创建符号链接，而那几个用例测的正是基于符号链接的越权防护。与本改动无关，CI（Linux）上不会出现。Compliance / 合规自检
AI 使用说明：本 PR 是考核任务的一部分，考核明确允许使用 AI 工具（不限工具与用法）。设计与功能实现由贡献者与 AI 编码工具（Claude Code）协作完成，功能代码主要由 AI 生成。已知 GOVERNANCE.md §6.2 对主要由 AI 生成的实现类 PR 有明确限制，此处如实披露，不声称符合该条政策。贡献者已逐行审阅代码，并确认了每一处设计决策 ，这些理由均已写入代码注释，可在评审中逐条说明。
dist/,dist-electron/, compiled.jsfrom.ts) / 未提交构建产物.env/ personal vault data committed / 无敏感信息Checklist / 自检清单
fix(live-preview): …；packages/core未新增任何导出live-preview-table.ts→ walked through the 12 Table Widget rules in CLAUDE.md / 已核对 12 条表格规则 ，本改动只涉及行号解析，不触碰交互状态机。Screenshots / Recordings · 截图或录屏 (UI changes)
default.mp4
default.mp4