fix(docs): render native bullets and contiguous code blocks in markdown append (#594)#627
Merged
Merged
Conversation
…wn append (openclaw#594) `docs write --markdown --append` previously inlined a literal `• ` or `1. ` prefix into the text run for list items, leaving the resulting paragraph as `NORMAL_TEXT` with the glyph baked into the content. Fenced code blocks were emitted as one Courier-styled `NORMAL_TEXT` paragraph per source line with no paragraph-level background, because the embedded `\n` characters split each line into its own paragraph. Fix the shared `MarkdownToDocsRequests` converter (used by both the append path and the `find-replace` markdown path) so that: - `MDListItem` and `MDNumberedList` emit a bare paragraph and a `CreateParagraphBullets` request with `BULLET_DISC_CIRCLE_SQUARE` or `NUMBERED_DECIMAL_NESTED`, matching the bullet plumbing already used by `docs_sed_helpers.buildParagraphStyleRequests` and `docs_sed_nesting`. The literal glyph prefix is gone, so inline text styles no longer need to be shifted past it. - `MDCodeBlock` joins source lines with `\v` (Docs soft line break) so the whole fenced block stays in a single paragraph, then applies an `UpdateParagraphStyle` with `Shading.BackgroundColor` (light grey) across the range. The `Courier New` text style is still applied to the run. Regression test in `docs_formatter_test.go` asserts the InsertText payload no longer contains literal `• ` or `1. ` prefixes, that code-block lines are joined by `\v`, and that `CreateParagraphBullets` + paragraph shading are emitted with the expected presets.
steipete
force-pushed
the
fix/594-append-bullets-code
branch
from
1b383dd to
8039ff4
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.
Summary
Fixes #594.
docs write --markdown --appendproduced two visibly broken outputs on v0.17.0:NORMAL_TEXTparagraphs with a literal•glyph (or1.) sitting in the text run, instead of nativeBULLETparagraph style.Courier NewNORMAL_TEXTparagraphs with no paragraph background, instead of a single contiguous shaded code block.Both issues live in
MarkdownToDocsRequestsininternal/cmd/docs_formatter.go, which is the shared converter used by both the--appendpath and thefind-replace --format=markdownpath. Thedocs create --file --markdownpath was unaffected because that path uploadstext/markdownto Drive and lets Drive do the conversion — it doesn't touch this converter at all.Changes
MDListItem/MDNumberedList: stop emitting a literal"• "/"1. "text prefix. Emit a bare paragraph and add aCreateParagraphBulletsrequest withBULLET_DISC_CIRCLE_SQUARE(orNUMBERED_DECIMAL_NESTED) over its range. Inline text styles no longer need a prefix offset.MDCodeBlock: replace embedded\nwith\v(Docs soft line break) so the whole fenced block lives in one paragraph, then apply paragraph-levelShading.BackgroundColor(light grey) across the range. MonospaceCourier Newis still applied as a text style.TestMarkdownToDocsRequests_AppendBulletsAndCodeindocs_formatter_test.gocovering both bullet/numbered presets and the code-block soft-break + shading path, plus a negative assertion that no literal•glyph survives in anyInsertTextpayload.Scope vs #592
The issue hints that #594 might share a root cause with #592 (table insertion failing in the same
--append --markdownpath). After tracing both, they're independent failures:MarkdownToDocsRequests— pure request shaping.TableInserter.InsertNativeTableproblem ("table not found near index N") — the post-batch lookup that finds the table to populate doesn't agree with the offsets that came out of the converter.Both bugs happen to surface on the
--append --markdownpath, but the fix points are different files and the fix here doesn't address #592. Keeping scope tight to #594 as requested; happy to follow up with #592 separately if useful.Test plan
go test ./internal/cmd/ -run "TestMarkdownToDocsRequests" -v— new + existing formatter tests pass.go test ./internal/cmd/— full cmd suite green (includingTestDocsWrite_MarkdownAppendUsesDocsFormatting,TestDocsWrite_MarkdownReplaceUsesDriveUpdate, all table/insert/sed coverage).go test ./...— all packages green.go vet ./internal/cmd/...— clean.gofmt -don edited files — no diff.🤖 Generated with Claude Code