Skip to content

fix: keep moved-line selections in view - #4156

Open
mvanhorn wants to merge 1 commit into
micro-editor:masterfrom
mvanhorn:fix/4134-movelinesup-scroll-follow
Open

fix: keep moved-line selections in view#4156
mvanhorn wants to merge 1 commit into
micro-editor:masterfrom
mvanhorn:fix/4134-movelinesup-scroll-follow

Conversation

@mvanhorn

Copy link
Copy Markdown

Summary

MoveLinesUp now keeps the moved selection in view by re-pointing the cursor at the selection endpoint it was already on before the view relocates. The same synchronization is applied to MoveLinesDown, whose compensation path has the identical structure.

Why this matters

Moving a multi-line selection upward can push the selected text above the viewport while the view stays put, so the selection scrolls out of sight (#4134). MoveLinesDown does not show the same behavior, which is what makes the bug feel arbitrary in normal editing.

The cause is a disagreement between two coordinate updates. The buffer edit event updates cursor and selection coordinates, and then MoveLinesUp applies its own newline-boundary compensation to CurSelection[sel]. When the cursor happens to sit on the endpoint being compensated, Cursor.Loc is left one line away from the endpoint it should track. Relocate scrolls to Cursor.Loc, so the view follows a stale position and the moved lines can end up off screen.

Changes

  • Record which selection endpoint the cursor is on before the move, and restore Cursor.Loc to that endpoint after the compensation step, in both MoveLinesUp and MoveLinesDown.
  • Add internal/action/movelines_test.go with regression coverage for both directions and both selection orientations.

Behavior is unchanged when there is no selection, at the first and last buffer line, and for selections taller than the viewport: the active endpoint is followed, with no attempt to fit an oversized selection on screen.

Testing

New tests cover:

  • top-down and bottom-up selections moved up across the viewport's top edge
  • active endpoints at and away from column zero, so newline-boundary compensation is exercised exactly once
  • a selection taller than the viewport, asserting the active endpoint is followed
  • downward movement across the bottom edge, confirming existing follow-scroll behavior still holds

Verified against master: the new tests fail without the change (cursor = {0 9}, active selection endpoint = {0 8}) and pass with it.

go build ./...                          # ok
go test ./internal/action/... -count=1  # ok
gofmt -l internal/action/...            # clean

Fixes #4134

MoveLinesUp applies its own newline-boundary compensation to the
selection after the buffer edit event updates coordinates. When the
cursor sits on the compensated endpoint, Cursor.Loc is left one line
away from the endpoint it should track, so Relocate scrolls to a stale
position and the moved selection can end up above the viewport.

Record which selection endpoint the cursor is on before the move and
restore Cursor.Loc to that endpoint after compensation, in both
MoveLinesUp and MoveLinesDown.

Fixes micro-editor#4134
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.

MoveLinesUp doesn't scroll the view to follow the selection when it moves above the viewport

1 participant