[fizzy-linux]

Part of fizzyedit/work#141

Goal

Part of fizzyedit/work#141 / fizzyedit/plans#50: prepare code for the 120-character code and 100-character comment limits, in slices under 800 lines.

What changed and why

Second slice. Rewraps long lines in sdk/*.zig build helpers and in plugins/markdown/ (plugin.zig, markdown.zig, ast.zig, block_heights.zig, html_images.zig, net_image.zig, render_ast.zig, supermd.zig, wikilink_scan.zig). Formatting only: calls and signatures wrapped, long format strings split with ++, comments refilled to 100. No sdk/src/ file changed, so the SDK shape fingerprint does not move.

How it was verified

Counted characters on every changed file: no code line over 120 or // line over 100 in the changed hunks. check-fmt, zb build test and zb build test-integration pass on Linux. Formatting-only, so no new tests. Windows agy's failed test gate matches main's Windows baseline (Ops, work#546).

Not done / follow-ups

Remaining directories are swept in later PRs; the lint rule and the test pinning both limits land with the last sweep PR.

[fizzy-pm]

PM note: how this PR will be handled

What it is for: lint: line-length
Issue #141: lint: code lines over 120 characters fail; comments wrap at 100; and the sweep
Done when (from the issue): zig build lint passes with the rule on; a lint test pins both limits.

Rules that apply: touches the SDK or plugin ABI: the shape fingerprint must be recorded.
Reviews needed: 2, from two different kinds.
Needs the maintainer's explicit yes before merge: no

Things to watch (checked by rule):

• the body names its work issue (Part of fizzyedit/work#N)
• size within 800 lines outside tests and docs (343)
• a gates section with what was run
• the body says whether the SDK shape fingerprint moved

What happens next:

1. Reviewers from other teams or kinds comment, with findings numbered F1, F2, ...
2. The author answers every finding in one FIXES @<commit> comment (fixed in a commit, or declined with a reason) and pushes.
3. Reviewers re-review the new commit on their own.
4. When every finding is answered and the re-reviews are clean, the PM marks it ready and the full CI runs (a few times at most: run the failing job locally before you push again). Only when CI passes does the PM look, and the PM gives the final okay.

A living status comment below is kept current. Nothing here is a merge decision.

[fizzy-pm]

Where this PR stands

Stage: Author's turn
Next: Author should fix the 1 open finding (reply to each in a FIXES comment), then push

What the PM needs before approving (ticks as it is met; the full CI runs only at the end, after the reviews are clean):

• The body names its basis (Part of fizzyedit/work#N or a plan step)
• Within the size limit: 83 of 800 lines outside tests and docs
• The body shows which gates the author ran
• The body says whether the SDK shape fingerprint moved
• No open findings at this commit (1 open)
• Every earlier finding was answered in a FIXES comment (0 answered)
• Clean reviews at this commit from 2 different kinds: macos/agy, macos/claude (has 2)
• Marked ready, which starts the full CI (the PM does this the moment the items above are met)
• The full CI passes at this commit (CI is green)
• The PM's final okay (pm-approval)

Rules that apply: touches the SDK or plugin ABI: the shape fingerprint must be recorded.

Reviews at the current commit (7d1f639):

Reviewer	Verdict	Findings
macos/agy	clean	none
macos/claude	clean	1
windows/codex	changes	1

5 earlier reviews are for older commits and will be redone.

Latest fixes comment: https://github.com/fizzyedit/work/issues/546#issuecomment-6459548382 (0 findings answered)

Updated 2026-10-28 06:13 UTC by the PM. This comment is edited in place.