barrettruth/ci.nvim
Watch
1
0
Fork
You've already forked ci.nvim
 0
Code Issues Pull requests Releases Packages Activity Actions

fix: open where :CI was asked from #36

Merged
barrettruth merged 1 commit from fix/open-in-the-window-you-asked-from into main 2026-07-28 06:08:04 +00:00
Conversation 0 Commits 1 Files changed 1 +8
barrettruth commented 2026-07-28 06:07:09 +00:00
Owner
Copy link

Checklist

  • I have read CONTRIBUTING.md.
  • No AI was used to generate, edit, or review any part of this contribution.

Problem

:CI resolves its target over the network — about 700ms for a revision — and
then opened the buffer in whatever window was current when the answer arrived.
Move in the meantime and it lands on top of the buffer you moved to.

Same shape as the TermClose handoff removed in #34: a deferred open taking a
window that is no longer the one you asked from.

Solution

Remember the window at invocation, return to it before opening, and fall back
to the current one if it has since closed.

invoked from win 1000, then immediately moved to win 1001

win 1001 -> CMakeLists.txt              (untouched)
win 1000 -> e3c5974adf25002ea490719…    (the checks)

nvim_win_call would have been the obvious tool and is wrong here: it restores
the previous window on return, which would undo M.open's jump to a window
already showing the buffer. Setting the current window plainly is both simpler
and correct, since landing in the buffer you asked for is the point.

## Checklist - [x] I have read [CONTRIBUTING.md](https://forge.barrettruth.com/barrettruth/ci.nvim/src/branch/main/CONTRIBUTING.md). - [ ] No AI was used to generate, edit, or review any part of this contribution. ## Problem `:CI` resolves its target over the network — about 700ms for a revision — and then opened the buffer in whatever window was current when the answer arrived. Move in the meantime and it lands on top of the buffer you moved to. Same shape as the `TermClose` handoff removed in #34: a deferred open taking a window that is no longer the one you asked from. ## Solution Remember the window at invocation, return to it before opening, and fall back to the current one if it has since closed. ``` invoked from win 1000, then immediately moved to win 1001 win 1001 -> CMakeLists.txt (untouched) win 1000 -> e3c5974adf25002ea490719… (the checks) ``` `nvim_win_call` would have been the obvious tool and is wrong here: it restores the previous window on return, which would undo `M.open`'s jump to a window already showing the buffer. Setting the current window plainly is both simpler and correct, since landing in the buffer you asked for is the point.
fix: open where :CI was asked from
All checks were successful
quality / Test (pull_request) Successful in 3s
Details
quality / Format (pull_request) Successful in 10s
Details
quality / Lint (pull_request) Successful in 12s
Details
e4ba24ddc2
 
Problem: Resolving a target is a round trip, and the buffer was opened in
whichever window happened to be current when the answer came back, so moving
in the meantime landed it on top of whatever you had moved to.

Solution: The window is remembered at invocation and returned to first, unless
it has since closed.
barrettruth deleted branch fix/open-in-the-window-you-asked-from 2026-07-28 06:08:04 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
barrettruth/ci.nvim!36
No description provided.