Skip to content

history: going back keeps deleted layers, merges, reorders and grids too - #62

Merged
foxnne merged 1 commit into
mainfrom
history/more-kinds-go-back
Oct 19, 2026
Merged

foxnne merged 1 commit into
mainfrom
history/more-kinds-go-back

Conversation

@foxnne

@foxnne foxnne commented Oct 19, 2026

Copy link
Copy Markdown
Contributor

Follows #59. Part of fizzyedit/plans#10 (plans/HISTORY_TIMELINE_PLAN.md step 4, "going back is a step").

What changes

#59 kept the steps gone back over only when every one of them was a kind that swaps its values the same way both ways. A jump over a deleted layer, a merge, a cell reorder or a grid change still lost them. Now all of those are kept:

  • A deleted or restored layer or animation flips its own restore/delete field and uses the file's deleted list in order. A plain copy reverses it. The line is only ever walked one step at a time, so that list stays in order with the steps.
  • A layer merge carries the destination's pixels and mask before the merge (deep-copied), and pops or pushes the deleted list in order.
  • A merge and a cell reorder act by direction (their undo is not their redo with values swapped). Their reverse is a copy marked inverted: running it as an undo does the original's redo, and the other way round. applyChange reads the flag in those two branches.
  • A grid change swaps a whole snapshot. Its copy is a deep copy of the snapshot.

A resize is the one kind left out (reversible). Its sprite data rides stacks beside the history, one set per resize, moving between undo and redo with its step. Its reverse would need a second set placed in the middle of those stacks. A jump over a resize, or a resize landing after going back, still drops what was gone back over, as before.

Verified

Live on macOS, in a sandbox fizzy with this pixi (built --fork to that fizzy's SDK), driven by an MCP client through the agent's bridge. Each case: a sprite with layers Top (one red pixel) and Layer; do the step; undo it; draw on Layer; then undo along the line.

Step after it undone undo the draw undo "Back to Draw" undo the step
delete Top Layer Top, Layer Top, Layer, red Layer (deleted again) Top, Layer, red
merge Top down Layer Top, Layer Top, Layer, red Layer, red (merged again) Top, Layer, red

The grid change and the cell reorder were not driven live; they build, and use the same copy and inverted paths. zig build (sandbox), zig fmt --check.

🤖 Generated with Claude Code

An edit after going back over a deleted or restored layer or animation, a
layer merge, a cell reorder or a grid change now keeps those steps on the
line with their reverses, as it already did for drawing. A merge and a cell
reorder, which act by direction, are taken back by an `inverted` copy. A
resize is the one kind still dropped.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@foxnne
foxnne merged commit 826772a into main Oct 19, 2026
6 checks passed
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