Repository navigation
docs: plans move to the private fizzyedit/plans - #296
Merged
Merged
Conversation
foxnne
force-pushed
the
docs/plans-private
branch
from
October 9, 2026 18:46
9705e66 to
5a25fb8
Compare
2 of 5 tasks
Fizzy's fifteen plans, reviews and handoffs (every docs/*_PLAN.md, REVIEW_*, TRANSITIONS_HANDOFF, LIB_CHECKPOINT) now live in the private fizzyedit/plans repo, open to the organization, so where fizzy is going can be worked out without every edit being public. The plugin contract, how automation works, the forks fizzy builds on, measurements and release notes stay here. References to a plan, in code comments and docs, read `plans/X.md`; markdown links point into the plans repo. CLAUDE.md says what that path means and where to clone it; CONTRIBUTING.md says plans and their issues live there, and that a PR here carries what a reviewer without access needs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
foxnne
enabled auto-merge (squash)
October 9, 2026 19:39
foxnne
force-pushed
the
docs/plans-private
branch
from
October 9, 2026 19:44
5a25fb8 to
f304d96
Compare
foxnne
added a commit
that referenced
this pull request
Oct 10, 2026
docs/AGENTS_PLAN.md and docs/AUTOMATION_PLAN.md moved to fizzyedit/plans (#296); their deletion stands here, and this branch's two edits to them go there (fizzyedit/plans#3). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
foxnne
added a commit
that referenced
this pull request
Oct 10, 2026
…298) Stacked on #296 (it adds `tests/data/markdown_sample_tables.md`, which this replaces). Retarget to `main` once that merges. ## What changes A markdown table whose cells wrap over many lines no longer changes height as the reader scrolls into it. The scrollbar no longer twitches by a line when paragraphs scroll back into view, either. The table-heavy test sample is now a generated document whose tables actually wrap. Both integration tests that guard this failed on it before the fix, and the old frozen plan copy hid the bug. **Why it moved.** Everything traces to one dvui behaviour: a text layout on its first frame wraps at an assumed 1000pt, not at the column, so it measures short. The preview's bookkeeping believed those measurements in four places: 1. **Table cells settled short.** A row measured only on budgeted frames, with skipped frames between, loses its text layouts in every gap, so every draw is a first frame. Two such draws agree perfectly, and the cell settled at the short height. A table re-entering the draw set also overwrote settled cells with short first-frame sizes. On the synthetic sample's last table, the final row settled 59pt short: 1789 measured off screen, 1730 on screen. Now a first-frame cell measurement never counts as a draw and never replaces a real size. It is kept (`provisional`) only when there is nothing better. 2. **Rows lagged a frame behind their cells.** The grid sizes a row from what its cells reported last frame. With (1) fixed, the cache stayed right but the grid did not, and a settled table measured short, *cleanly*, on the frame after a first-frame draw. Now a drawn cell with a settled size at this width is held to at least that height, as a culled cell already was. 3. **A pinned block was measured by its pin.** The wrapper emits exactly the pin, so a `.deferred` table came out of deferral with its untrusted height filed as a clean measurement. Now any pinned block is measured by its unconstrained inner box, which only pinned-above-the-fold blocks used to be. That also makes it safe to pin every block with a believed height, not only tables. A paragraph scrolled back into view emitted a line short for a frame. That was the remaining 19.6pt in "rapid scrolling up and down". 4. **`.measured` meant two things.** It meant both "clean at this width" and "laid out at a width that is gone". `record` must throw the second away for a contaminated measurement, so it threw the first away too. Stale heights are now their own state, `.stale`. `invalidateForWidth` also no longer turns a never-measured `.estimated` slot into a "measurement" of its zero placeholder. The task this came from guessed at the table *estimate* for wrapped cells. Instrumenting the failing block showed the estimate was never involved: the table settled at 1789.1 from a clean off-screen measurement, and the on-screen layout was the one that was wrong. **The sample.** `tests/data/markdown_sample_tables.md` is now generated by `tests/data/markdown_sample_tables.py` (seeded, so it reproduces exactly). It has one 48KB three-column table whose cells wrap over many lines, three smaller tables, and prose. After the tables come blocks that repeat word for word, so source hashes are not unique (the old sample had seven, which the traversal test relies on), and one long paragraph for bench-markdown's "prose" sample. Those come *after* the tables on purpose: content inserted above them shifted which scroll frames see the big table, and that alone hid the block-heights failure. The frozen plan copy at that path is gone. bench-markdown's "prose" sample now uses this document as well. ## SDK impact - [x] None ## Verified - [x] macOS: all five gates (`zig build`, `zig build test`, `zig build test-integration`, `zig build check-web`, `zig build test-sdk-version`). - On the parent, the new sample fails both tests: `block 29 changed height while scrolling: 1789.1 -> 1730.4`, and a rapid-scroll total of 18967.6 against 19476.0. With the fix, all 17 `markdown preview` integration tests pass. - With the fix, the 4-column `**Row N**` variant of the sample also passes all 17 (reported failing with `2610.4 -> 2297.5` before; I did not re-run that on the parent). So does the old frozen plan copy. - New unit tests in `block_heights.zig`: a contaminated measurement does not replace a clean one at the same width, and a width change leaves a never-measured block on its estimate. - [ ] Windows: - [ ] Linux: CI's `test-integration` - [ ] Web: `check-web` compiles. Not run in a browser. Not checked by eye in the running app. The evidence is the headless layout tests above. ## Follow-ups - Every block with a settled or deferred height is now pinned while drawn. A real change still gets through, one frame late: the inner box disagrees, the entry drops to `.measured`, and the pin comes off. That is the lag pinned-above-the-fold blocks already had. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
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
1 participant
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.
What changes
Fizzy's plans move to a private repo,
fizzyedit/plans, open to thefizzyeditorganization. Where fizzy is going can then be worked out without every edit being public.docs/*_PLAN.md, bothREVIEW_*docs,TRANSITIONS_HANDOFF.md,LIB_CHECKPOINT.md. The plans repo has them as ofmaina2b4e0a7, plus theAGENTS_PLAN.mdedits from app: a rebuilt plugin loads without freezing a frame #287, app: a rebuilt plugin is picked up without the settings coalesce #290, keymap: a plugin load no longer works out keybind conflicts nobody shows #291 and ci: measure a plugin's rebuild loop on Linux, per backend and incremental #292, so those PRs drop their doc changes.PLUGINS.md,AUTOMATION.md,DEPENDENCIES.md, the live-resize measurements, release notes,demos/.docs/PLUGIN_MANIFEST_PLAN.mdas their table-heavy sample (and the markdown bench as prose). It moves totests/data/markdown_sample_tables.mdas a frozen copy: that text was already public in this repo's history, the plan is essentially done, and later edits to it stay private. I tried a synthetic sample of the same shape first, and it exposed a real preview bug: a large table of wrapping rows gets a different height before and after it is laid out (block heights do not depend on where the reader isandrapid scrollingfail). That's filed separately rather than fixed here.plans/X.md(48 files). Markdown links point into the plans repo, which works for members.CLAUDE.mdsays whatplans/X.mdmeans, where to clone it, and that a session without access works from the code and public docs.CONTRIBUTING.mdsays plans and their issues live there, and that a PR here carries what a reviewer without access needs.What this doesn't do: fizzy's history still holds every plan as it was. Moving them hides future edits only; rewriting history would break every clone.
SDK impact
Verified
zig build test-integration: 33/33 steps, 347/347. No reference to a moved file is left.Follow-ups
docs/AGENTS_PLAN.mdanddocs/WORKSPACES_PLAN.md. Its plan edits belong in the plans repo once this lands.AGENTS_PLAN.mdedits, which are already in the plans repo.🤖 Generated with Claude Code