feat(extensions): line-exact review navigation with ctx.navigation.revealLine - #727
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
elucid
force-pushed
the
elucid/reveal-line
branch
from
August 13, 2026 20:35
39cd7d2 to
1e42375
Compare
elucid
marked this pull request as ready for review
August 13, 2026 23:44
Contributor
Greptile SummaryThe PR adds line-exact extension navigation and hardens live pane navigation callbacks. The previously reported race between cross-file selection retries and exact-line placement is fixed.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains; the previously reported selection retry is cancelled before exact-line scrolling and the regression path is covered. Important Files Changed
Sequence DiagramsequenceDiagram
participant E as Extension
participant N as Navigation Guard
participant R as Review Controller
participant D as DiffPane
E->>N: revealLine(fileId, side, line)
N->>N: Validate visible file and coordinates
N->>R: Reveal matching cursor or select containing hunk
R->>D: Selection and line-reveal request
D->>D: Cancel pending selection retries
D->>D: Scroll exact line to host reveal position
Reviews (2): Last reviewed commit: "fix(ui): let a revealed line survive the..." | Re-trigger Greptile |
elucid
added a commit
that referenced
this pull request
Aug 14, 2026
A cross-file revealLine changes the selected file, and the selection reveal that schedules runs a zero-delay retry after this layout effect — dragging the viewport from the named line back to the hunk anchor, 51 rows away in the regression test. The neighbouring explicit-alignment effect already retires that work through supersedePendingSelectionReveal; a named line is just as authoritative, so it does the same. Reported by Greptile on #727.
elucid
added a commit
that referenced
this pull request
Aug 14, 2026
A cross-file revealLine changes the selected file, and the selection reveal that schedules runs a zero-delay retry after this layout effect — dragging the viewport from the named line back to the hunk anchor, 51 rows away in the regression test. The neighbouring explicit-alignment effect already retires that work through supersedePendingSelectionReveal; a named line is just as authoritative, so it does the same. Reported by Greptile on #727.
elucid
force-pushed
the
elucid/reveal-line
branch
from
August 14, 2026 03:59
e616156 to
f756f53
Compare
elucid
force-pushed
the
elucid/reveal-line
branch
from
August 14, 2026 04:50
f756f53 to
cf68c9f
Compare
elucid
changed the base branch from
main
to
fix/line-highlight-review-followups
August 14, 2026 04:50
elucid
changed the base branch from
fix/line-highlight-review-followups
to
main
August 14, 2026 15:52
selectHunk was the finest target an extension had, so a match on line 211 of a 300-line hunk landed the viewport on the hunk anchor, pages above the thing the extension had just marked. revealLine names the line itself, and the guard refuses a hidden file, a side outside the two diff sides, and a line number no patch could have written.
The line-cursor machinery already resolves a measured row and scrolls to it, but its stepping policy moves the minimum distance, which leaves a jump to a line that happens to be on screen exactly where it was. Give the reveal request an explicit placement so a jump lands the line where hunk and note reveals land theirs, and resolve (side, line) against the stops measured for every visible file so a cross-file jump needs no second pass. A line no measured row covers degrades to its hunk.
…ssion The regression this guards is spatial, so assert it where the user sees it: the marked line is off screen while the hunk anchor is selected, and one revealLine command puts it in the top half of the terminal.
An extension author needs to know two things the signature does not say: where the revealed line lands (the app's own reveal position, not the caller's choice) and what happens to a line the stream cannot draw. The pack check exercises the new method so the published surface stays honest, and the proposal's companion-gap section now records the design rather than proposing it.
The session's first deferred search jump landed on the hunk anchor - the exact behavior revealLine exists to fix. A memoized extension pane keeps its mount-time actions (the API documents them as valid while mounted), and the revealLine minted on that first render closed over App's cursor state before the diff pane had published any measured stops, so findLineCursorAt saw an empty list and silently degraded to the hunk fallback. selectHunk never showed this because it only dispatches through stable store callbacks; revealLine is the first navigation member that reads data. Read the cursors and visible files through refs so any held reference - a memoized pane's actions, an async handler after an await - resolves against the review as it is now.
A cross-file revealLine changes the selected file, and the selection reveal that schedules runs a zero-delay retry after this layout effect — dragging the viewport from the named line back to the hunk anchor, 51 rows away in the regression test. The neighbouring explicit-alignment effect already retires that work through supersedePendingSelectionReveal; a named line is just as authoritative, so it does the same. Reported by Greptile on #727.
The proposal was pre-implementation design rationale — the kind of document that belongs in a PR description, not shipped docs — and it kept drawing rebase conflicts as the stack evolved. Everything it documented that users need survives in the real documentation: the line-highlight and revealLine API contracts in docs/extensions.md and website/src/content/docs/docs/extend/extension-api.md, the subsystem map in docs/extension-architecture.md, and the corrective notes from the post-merge review (zero-width ranges paint nothing; transparent cells resolve tints against an assumed background) in those same pages and src/extension-api/types.ts.
elucid
force-pushed
the
elucid/reveal-line
branch
from
August 14, 2026 16:10
cf68c9f to
026dd45
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Stacked on the line-highlights PR. Extension navigation gains its missing granularity:
selectHunkwas previously the finest target an extension could name. That is fine until the hunk is large: a search extension can highlight a match on line 211, report "line 211" in its status — and the viewport still sits at the hunk anchor, pages above the match.revealLinescrolls the exact line into view and places the host's line cursor on it.Design
max(2, 25% of viewport)rows of context above — the same policy note-to-note navigation and hunk reveals already use. Deliberately no placement option in the API: the extension states intent ("show this line"), the host owns presentation, and one learned landing zone beats per-extension conventions. Users can nudge afterwards with the align-current-line commands.selectHunktoday. Only a line no hunk covers warns.revealLinewas the first navigation member to read review state from its closure. It now reads through render-updated refs, so any held reference — memoized pane actions, an async handler navigating after anawait— acts on the review as it is now, which is what the documented contract ("actions stay valid for as long as the component is mounted") always promised. Regression-tested at unit, host-PTY, and end-to-end-PTY levels, each demonstrated failing pre-fix.What this unlocks
Paired with line highlights, marks and navigation compose into "look here":
Notes
elucid/line-highlights); that PR squash-merged intomain, and this branch is now rebased ontomainwith only its own six commits.revealLineships in the same generation and the docs describe both under one version note ("Version 5 adds line highlighters and line-granular navigation"). If v5 ships in a release before this lands,revealLinemust become v6.revealLineinto the core review intent vocabulary (aselection/reveal-lineintent, a new reveal anchor, or moving the line-cursor reveal request into the review store). Line-cursor reveals are controller-local onmaintoday, so this stays controller-local too; lowering it is a separate change if another surface ever needs line-exact reveals.selection/anchorintent (the replacement for the oldpreserveViewportoption); the placement policy ("reveal"for jumps,"nearest"for stepping) is unchanged.