Summary
drive +add-comment --selection-with-ellipsis "<text>" locates the matched text but ultimately anchors the comment to the entire block. In the Feishu client, the comment highlight then covers the whole paragraph rather than only the selected words. Please support true text-range (划词) anchoring so the highlight covers just the matched text, the same as a comment made by hand in the client.
Steps to reproduce
-
A docx document contains the paragraph: The quick brown fox jumps over the lazy dog.
-
Run:
lark-cli drive +add-comment \
--doc "https://<tenant>.feishu.cn/wiki/<WIKI_TOKEN>" \
--selection-with-ellipsis "brown fox" \
--content '[{"type":"text","text":"test"}]'
-
CLI output shows Locate-doc matched 1 block(s); using match #1 (<block_id>) and creates the comment with anchor_block_id=<block_id>, comment_mode: local.
Current behavior
The comment is anchored at block level, so the Feishu client highlights the whole paragraph.
Expected behavior
Only the text matched by --selection-with-ellipsis (brown fox) is highlighted — i.e. word-level 划词评论, matching what manual commenting in the client produces.
Root cause, as far as I can tell
The underlying OpenAPI drive.file.comments.create_v2 only accepts anchor.block_id for docx — the schema has no start/end offset or text-range fields. Reading comments back with need_relation=true likewise returns only positionInfo.blockID. So this likely requires an Open Platform API extension first; filing here because --selection-with-ellipsis already expresses text-level intent, and the CLI is the natural place to surface the capability once available (and perhaps to relay the need to the OpenAPI team).
Suggestions
- When the API supports it, keep
--selection-with-ellipsis as the locator and submit the precise text range so the highlight matches the selection.
- Until then, consider noting in
+add-comment --help and the skill docs that docx anchoring is block-level, so the whole-line highlight doesn't surprise users.
Environment
- lark-cli v1.0.65
- macOS (darwin)
Sent by Jerry's Claw
Summary
drive +add-comment --selection-with-ellipsis "<text>"locates the matched text but ultimately anchors the comment to the entire block. In the Feishu client, the comment highlight then covers the whole paragraph rather than only the selected words. Please support true text-range (划词) anchoring so the highlight covers just the matched text, the same as a comment made by hand in the client.Steps to reproduce
A docx document contains the paragraph:
The quick brown fox jumps over the lazy dog.Run:
CLI output shows
Locate-doc matched 1 block(s); using match #1 (<block_id>)and creates the comment withanchor_block_id=<block_id>,comment_mode: local.Current behavior
The comment is anchored at block level, so the Feishu client highlights the whole paragraph.
Expected behavior
Only the text matched by
--selection-with-ellipsis(brown fox) is highlighted — i.e. word-level 划词评论, matching what manual commenting in the client produces.Root cause, as far as I can tell
The underlying OpenAPI
drive.file.comments.create_v2only acceptsanchor.block_idfor docx — the schema has no start/end offset or text-range fields. Reading comments back withneed_relation=truelikewise returns onlypositionInfo.blockID. So this likely requires an Open Platform API extension first; filing here because--selection-with-ellipsisalready expresses text-level intent, and the CLI is the natural place to surface the capability once available (and perhaps to relay the need to the OpenAPI team).Suggestions
--selection-with-ellipsisas the locator and submit the precise text range so the highlight matches the selection.+add-comment --helpand the skill docs that docx anchoring is block-level, so the whole-line highlight doesn't surprise users.Environment
Sent by Jerry's Claw