Skip to content

app: scrubbing the history no longer retakes its steps' pictures - #660

Merged
foxnne merged 1 commit into
mainfrom
app/history-pictures-immutable
Oct 19, 2026
Merged

foxnne merged 1 commit into
mainfrom
app/history-pictures-immutable

Conversation

@foxnne

@foxnne foxnne commented Oct 19, 2026 •

Copy link
Copy Markdown
Collaborator

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, historyGoTo and scrub landing re-captured the pane and replaced what the step had (fetchOrderedRemove + put in HistoryFrames.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:

  • The editor reads the track's records since the last move (HistoryFrames.changeOf). An added or joined record 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.
  • A new track for a document that had one (a restart, 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.
  • Anything else (undo, redo, go-to, a scrub, the "going back is a step" re-push of old entries, text: going back is a step, so an edit after it loses nothing #571) is a visit: it only fills in a picture the step lacks, compared with the step truly before it on the line (below, from historyLine), never the last position visited. A visit's picture that lands after the step got one is dropped.
  • One exception keeps pictures from going stale: a visit retakes a step whose picture was taken from a different pane size (Picture.source against the pane as it stands, pane_source), the window resized since, so a strip never mixes two views.
  • A retake no longer carries the old picture's change box over: the only retakes left are of a step that changed, or of another view, where the old box is wrong.

SDK impact

  • None

Verified

  • macOS: 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; changeOf tells made, joined, visited and restarted apart), plus the gates below.
  • Windows:
  • Linux: CI test-integration.
  • Web: zig build check-web.

Follow-ups

None.

🤖 Generated with Claude Code

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
foxnne force-pushed the app/history-pictures-immutable branch from 8a36859 to db1f6de Compare October 19, 2026 19:24
@foxnne
foxnne marked this pull request as ready for review October 19, 2026 19:24
@foxnne
foxnne enabled auto-merge October 19, 2026 19:25
@foxnne
foxnne added this pull request to the merge queue Oct 19, 2026
Merged via the queue into main with commit e67e795 Oct 19, 2026
11 checks passed
@foxnne
foxnne deleted the app/history-pictures-immutable branch October 19, 2026 19:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant