On Mon, Jul 25, 2022 at 02:54:29AM +1000, Mark Jamsek wrote:
> I got the idea from stsp the other day when he mentioned that he doesn't
> always navigate diffs linearly, and I started paying close attention to
> how I read diffs. He's right--sometimes I jump around a fair bit too,
> and sometimes I read them top to bottom. In both cases, I find these key
> maps help navigating diffs.
> 
> Two new sets of key maps are proposed:
>   P - jump to the previous file
>   N - jump to the next file
>   { - jump to the previous hunk
>   } - jump to the next hunk
> 
> Next and previous are relative to the current line, and they work with
> a count prefix too.
> 
> NP in particular are helpful in large diffs of multiple files; often
> I want to read the man page first (if the diff involves user-facing
> changes) to get an idea of what the implementation should do, then after
> reading the code, I may want to jump back and forth from the docs if,
> for example, I'm scrutinising something. But {} are also handy,
> especially if, like me, you want to start reading a new section from the
> top of the page. Or if the diff contains blocks of moved code (e.g.,
> op's recent 'got path -R' change in 38d61ead4), it's nice to be able to
> quickly jump to the next hunk.

I find this interesting, I've tested the patch - works fine, but I have
on question - if, for example, we have two files changed, and I press N
N N (3 times), it cycles me back to first file (same with hunks). Is it
intentional? My first expectation would be not to cycle the search, but
stop if I hit N/} on the last file/hunk. Same with previous keybinding.