Skip to content

fix(status-bar): refresh cached cursor line on plugin cursor jump (#2301)#2333

Open
sinelaw wants to merge 1 commit into
masterfrom
claude/upbeat-maxwell-25plh2
Open

fix(status-bar): refresh cached cursor line on plugin cursor jump (#2301)#2333
sinelaw wants to merge 1 commit into
masterfrom
claude/upbeat-maxwell-25plh2

Conversation

@sinelaw

@sinelaw sinelaw commented Jun 14, 2026

Copy link
Copy Markdown
Owner

Fixes #2301.

Problem

After Go to LSP Symbol jumps the cursor, the status bar shows the previous line number (Ln 30) with the new column (Col 5) until the next keypress, which self-corrects it. The cursor itself lands correctly — only the status-bar line readout is stale, right after the command whose whole purpose is to navigate there.

Root cause

The "Go to LSP Symbol" plugin moves the cursor through the setBufferCursor plugin op, handled by Window::set_buffer_cursor_in_splits. That function moved the cursor position but never refreshed state.primary_cursor_line_number.

The status bar (status_bar.rs) reads the line from that cached primary_cursor_line_number, while it computes the column live from the cursor's byte position. That asymmetry is exactly the reported symptom: column updates, line is stale until any later cursor movement recomputes the cache.

This is the same class of bug noted in the issue comment ("status bar not refreshed after a programmatic cursor jump") for any path that bypasses the canonical jump entry point.

Fix

Refresh the cached line number inside set_buffer_cursor_in_splits after moving the cursor, mirroring the canonical Window::jump_active_cursor_to. This covers every plugin-driven cursor jump that uses setBufferCursor, not just the LSP symbol case.

Testing

  • Added test_lsp_navigation_status_bar_line_updates_after_jump: jumps to myMethod (file line 5) and asserts the status bar reads Ln 6, Col 3 immediately, with no intervening cursor movement. The pre-existing test_lsp_navigation_jumps_to_precise_column only asserted the column, which is why the stale line went unnoticed.
  • Verified the new test times out / fails without the fix (the status bar never shows the new line) and passes with it.
  • All 8 lsp_navigation e2e tests pass; cargo fmt --check and cargo clippy are clean.

https://claude.ai/code/session_015Cs1411QRfGHJzz2cjsczW


Generated by Claude Code

@sinelaw sinelaw force-pushed the claude/upbeat-maxwell-25plh2 branch 2 times, most recently from 5b3cc65 to a4a74d2 Compare June 22, 2026 19:43
)

"Go to LSP Symbol" moves the cursor through the `setBufferCursor` plugin
op (`set_buffer_cursor_in_splits`), which updated the cursor position but
never refreshed `state.primary_cursor_line_number`. The status bar reads
the line from that cache while computing the column live, so right after
the jump it reported the pre-jump line ("Ln 30") with the new column
("Col 5") until the next cursor movement recomputed the cache.

Refresh the cached line number after the jump, mirroring the canonical
`Window::jump_active_cursor_to` path. This fixes every plugin-driven
cursor jump (Go to LSP Symbol and any other `setBufferCursor` caller),
not just the LSP case.

The existing `test_lsp_navigation_jumps_to_precise_column` only asserted
the column, which is why the stale line went unnoticed; the new
regression test asserts the full `Ln 6, Col 3` immediately after the
jump, with no intervening cursor movement.
@sinelaw sinelaw force-pushed the claude/upbeat-maxwell-25plh2 branch from a4a74d2 to 73791b5 Compare June 23, 2026 04:52
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.

Go to LSP Symbol: status bar line number stays stale after jump (only column updates) until next keypress

2 participants