Change navigation
Step through a comparison with ‹ › or ⌥↑/⌥↓. There is exactly one index behind all of it, which is why the strip, the keys and the scroll position can never disagree.
Every comparison offers the same way through it: a stepper in the summary strip, and a pair of keys.
| Control | Action |
|---|---|
› in the strip, or ⌥↓ | Next change |
‹ in the strip, or ⌥↑ | Previous change |
The stepper reads n / m, and shows – for the position until you take your first step — nothing is selected when a result first opens.
One index, registered by the view#
The engine view is the only thing that knows what its rows mean, so it declares two things: how many changes there are, and how to reveal one. The chassis owns which change you are on.
That split is the whole design. If the summary strip counted changes itself, or the keyboard tracked its own position, there would be three answers to "which change is current" and no reason for them to agree. Instead there is one, and the strip, the keys, the scroll position and — where an engine has one — its own change list are all reading it.
What counts as "a change", per engine#
Each engine decides, because the unit differs.
| Engine | One stop is | Notes |
|---|---|---|
| Text and code | Every row that is not context and not a fold | A modified line is one stop even in unified mode, where it paints as two rows |
| JSON | Every visible row that is not a container and is neither unchanged nor ignored | Containers are not stops: their state is derived from their children |
| Folders | Every visible file row that is not identical | Directories are not stops |
| Images | Each changed region | The sidebar's region list is the same index — clicking a region is navigating to it |
| Binary | Nothing | There is no detail to step through, so the stepper does not appear |
Note the word visible for JSON and folders. In those engines the search box and the status filters remove rows, and the count follows: ‹ n/m › describes what is on screen, not what the engine found before you filtered it. See search and filter.
When the count changes#
Re-registering resets the position to –. That happens when the set of changes genuinely becomes a different set: a filter changes, a normalisation option re-runs the comparison, or you open a different pair. Keeping an old index against a new list would point at the wrong row, which is worse than starting again.