Repository navigation
app: scrubbing the history no longer retakes its steps' pictures - #660
Merged
Merged
Conversation
A step's picture in the history strip was taken again every time the history moved onto it: each undo, redo and scrub landing re-captured the pane and replaced what the step had, so sliding the scrubber changed the snapshots (their crop and change box shifting with the pane and the frame caught). Now a step's picture is taken once, as the step is made, and kept. The editor reads the track's records since the last move (`HistoryFrames.changeOf`): an `added` or `joined` record for the entry on top retakes it (a run of typing keeps one step whose picture follows it), a new track (the history restarted) lets go of every picture, and anything else is a visit, which only fills in a picture the step lacks, compared with the step truly before it on the line, or retakes one taken at another pane size. A visit's picture that lands after the step got one is dropped.
foxnne
force-pushed
the
app/history-pictures-immutable
branch
from
October 19, 2026 19:24
8a36859 to
db1f6de
Compare
foxnne
marked this pull request as ready for review
October 19, 2026 19:24
foxnne
enabled auto-merge
October 19, 2026 19:25
foxnne
added a commit
that referenced
this pull request
Oct 19, 2026
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
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.
Fixes the maintainer's report on main (58cdcb1, after #653 and #656): "sliding the scrubber on the history seems to modify the snapshots of each step".
What changes
A step's picture in the history strip was taken again every time the history moved onto it: each undo, redo,
historyGoToand scrub landing re-captured the pane and replaced what the step had (fetchOrderedRemove+putinHistoryFrames.land), so sliding the scrubber changed the snapshots, their crop and change box shifting with whatever the pane showed at that frame.Now a step's picture is taken once, as the step is made, and kept:
HistoryFrames.changeOf). Anaddedorjoinedrecord for the entry on top is the step being made: its picture is (re)taken, so a run of typing, one step whose id stays put, still ends with a picture of the whole run.Tracks.step: reload from disk, a restore) lets go of every picture: none is of the new history, whose ids may repeat the old ones.below, fromhistoryLine), never the last position visited. A visit's picture that lands after the step got one is dropped.Picture.sourceagainst the pane as it stands,pane_source), the window resized since, so a strip never mixes two views.SDK impact
Verified
zig build test(new tests: scrubbing to and fro across five steps leaves every stored picture's prints, source and change as taken, and nothing is asked to be taken;changeOftells made, joined, visited and restarted apart), plus the gates below.test-integration.zig build check-web.Follow-ups
None.
🤖 Generated with Claude Code