Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Stepping through a review with ] can pass content that never reached the screen

Aperta
  • Qualcosa non va?
#405 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
38/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
developer-experience

Direzione di ricerca

Start by reading app/ui/model.go around pendingHunkJump and pendingAnnotJump, then trace how ] and [ navigate hunks and annotations. The issue lays out alternative interaction designs but leaves the desired approach undecided, so first determine how those actions and config are structured. Done means one key can step through every hunk and annotation across files, with boundary behavior and documentation in README, site/docs.html, and the plugin references/usage.md.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Context

I lean heavily on ] to step through a review, with this in ~/.config/revdiff/config:

cross-file-hunks = true

The problem is that ] can move past content that never reached the screen:

  • A hunk taller than the viewport lands with its first line near the top. The next ] goes to the following hunk, so the rest of the tall one is never shown.
  • Annotations outside a hunk get skipped: file-level ones, ones on context lines, and ones above the first hunk of a file ] crosses into.

So when I reach the last hunk, I can't tell whether I've seen everything. Today I check with a second pass on } or by opening @.

Options

Is this worth solving, and if so, how would you approach it? Here are the shapes I can see, in case they help.

A. Separate next_step / prev_step actions

A new pair of actions that steps through hunk starts and annotations, in file order, across files. ], [, }, { stay as they are.

The default keys would be s / S, both unbound, following the n / N pattern for forward and back. Anyone who wants to step with ] rebinds it in ~/.config/revdiff/keybindings:

map ] next_step
map [ prev_step

Pros: existing keys keep their meaning; no new option.
Cons: two more actions that overlap ] and }; a third file-crossing landing intent next to pendingHunkJump and pendingAnnotJump.

B. Configurable stops for ] / [

Turn cross-file-hunks into a list of what ] / [ do, the same way include / exclude take a list. Working name step, since the key is no longer stepping through hunks alone:

step = cross-file,annotations
Value ] / [ also
cross-file crosses file boundaries (today's cross-file-hunks = true)
annotations stops at annotations outside hunks, including file-level ones

cross-file-hunks = true would keep working as step = cross-file.

Pros: no new keys; one setting for anyone who already steps with ].
Cons: ] means different things depending on config; a bool option migrates to a list.

Tall hunks

The tall-hunk case is a separate but related concern, and neither shape above covers it. It reads more like a viewport setting next to wrap than a stop type: working name show-more, where ] on a hunk taller than the viewport scrolls through the rest of it before moving to the next one.

Acceptance criteria

  • Existing behavior is unchanged by default; any change to how ], [, }, { behave is opt-in.
  • One key steps a review through every hunk and every annotation, crossing files.
  • Past the last step (or before the first), the key does nothing, as ] / [ do today at the last / first hunk.
  • README, site/docs.html, and the plugin references/usage.md copies cover whichever shape lands.
Lingua principale
Go
Stelle
928
Fork
96
Merge medio
2g 3h
PR unite (30g)
28

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di umputun/revdiff

Tutte le issue di umputun/revdiff

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.