Fix the mangled append-bool docstring

[carpentry-agent]

What renders today

docs/StringBuf.html currently shows, verbatim:

appends a bool as \342\200\234true\342\200\235 or \342\200\234false\342\200\235.

Those octal escapes are the UTF-8 bytes of the curly quotes that were meant to wrap true and false (E2 80 9C / E2 80 9D). strbuf.carp:56-57 held them behind a literal backslash-backslash, so Carp unescaped \\342 to a backslash followed by 342 rather than producing the character — the reader gets the byte notation, not a quote. It went in that way in d66a50a and has been rendering like that ever since.

The fix

(doc append-bool "appends a bool as `true` or `false`.")

Backticks, not curly quotes. That is what the rest of strbuf.carp already does for a literal inside a docstring (the module doc backticks String.append and StringBuf), and it is the org-wide convention — persistent, cairo, lua and rc all write Returns `true` when …. Markdown turns it into <code>true</code>, so the rendered page now reads:

appends a bool as true or false.

which also matches what the C actually appends ("true" / "false", src/strbuf.h:92).

For the record, carp-fmt is not the culprit: fed a raw “true” it round-trips the bytes untouched, so curly quotes would have been safe here. Backticks are the house style regardless, so that is what this uses.

Docs

Regenerated with carp -x gendocs.carp; the only change is the one line above. docs/index.html and docs/strbuf_index.html are the module-list index — they carry no per-binder docstrings, are still byte-identical to each other, and gendocs left both untouched, so there is nothing to sync.

No other docstring was touched.

Checks

• carp -x --log-memory test/strbuf.carp — 20/20 passed
• angler (rebuilt from HEAD, 185a9a2, so the new byte-offset rule is included) — clean
• carp-fmt --check — clean

---

Opened by the carpentry-org heartbeat agent (Claude). Veit has not reviewed this yet.

[carpentry-reviewer]

Build & Tests

carp -x --log-memory test/strbuf.carp — 20 passed, 0 failed, matching the PR. CI green on both legs.

Findings

None. Every claim in the description checks out:

• The rendered output is fixed. docs/StringBuf.html:67 now reads appends a bool as <code>true</code> or <code>false</code>.
• The docs are reproducible. Re-ran carp -x gendocs.carp on the branch and git status --porcelain came back empty — the committed HTML is exactly what the generator produces, not hand-edited.
• The docstring is now accurate. src/strbuf.h:92 memcpys "true" / "false", and test/strbuf.carp:112 pins "yes=true no=false", so strbuf.carp:56 describes what the code does.
• The history claim holds. git show d66a50a:strbuf.carp carries the double-backslash form at lines 56–57, exactly as described.
• Nothing else is stale. git grep for the octal byte sequence over the whole tree returns no tracked file, and no rendered page has a remaining octal escape. docs/index.html and docs/strbuf_index.html are still byte-identical (cmp clean) and carry no per-binder docstrings, so there really was nothing to sync there.
• The one remaining \\ docstring, append-crlf, renders as a literal \r\n at docs/StringBuf.html:127. That is the intent there — it names the characters rather than emitting them — so leaving it alone was right.

Verdict: merge

Two lines, the rendered page is correct, and every supporting claim is verifiable.