Skip to content

fix(tree): stop swapping Offset start and end#676

Open
c-tonneslan wants to merge 1 commit into
charmbracelet:mainfrom
c-tonneslan:fix/tree-offset-swap
Open

fix(tree): stop swapping Offset start and end#676
c-tonneslan wants to merge 1 commit into
charmbracelet:mainfrom
c-tonneslan:fix/tree-offset-swap

Conversation

@c-tonneslan

Copy link
Copy Markdown

Closes #535.

`Tree.Offset(start, end)` is documented (via `list.Offset`) such that `start` counts from the beginning and `end` counts from the end:

Offset(1, -1) on [A, B, C, D] shows [B, C, D]

The implementation swapped `start` and `end` whenever `start > end`, so `Offset(2, 1)` on the duckduckgoose example (["Duck", "Duck", "Duck", "Goose", "Duck"]) ended up acting like `Offset(1, 2)` and rendered the first two Ducks instead of the third Duck plus the Goose. The two arguments aren't interchangeable coordinates, so the swap was wrong.

While I was in there I also tightened the bounds: `start` and `end` are both clamped to `[0, length]`, and `end = -1` (the "skip nothing from end" idiom in the docs example) is normalized to `0` instead of clamping to `length` (which previously made the loop in render iterate over zero elements).

Test plan

```
go test ./...
```

Added two new unit tests in `tree/tree_test.go`:

  • `TestTreeOffsetAsymmetric` — the case from the issue, `Offset(2, 1)` on five children leaves exactly one Duck and the Goose visible.
  • `TestTreeOffsetClampsNegative` — `Offset(-5, -5)` is a no-op and the full child list still renders.

Tree.Offset(start, end) is documented (via list.Offset) so that start
counts from the beginning and end counts from the end, e.g. Offset(1, -1)
on [A,B,C,D] shows [B,C,D]. The previous implementation swapped start and
end whenever start > end, which made Offset(2, 1) on the duckduckgoose
example render the first two Ducks instead of the third Duck and the
Goose. The two arguments aren't interchangeable coordinates, so the swap
was wrong. Closes charmbracelet#535.

Also tightened the bounds handling: start and end are now both clamped to
[0, length], and end=-1 (the "skip nothing from end" idiom shown in the
docs) is normalized to 0 instead of being treated as "skip everything"
which had its own off-by-everything bug.

Added two unit tests, one for the asymmetric case from the issue and one
for the negative-clamp invariant.

Signed-off-by: Charlie Tonneslan <[email protected]>
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.

Tree Offset logic is broken

1 participant