On Mon, Jul 25, 2022 at 03:24:42AM +1000, Mark Jamsek wrote:
> On 22-07-25 02:54am, 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
> > 
> 
> Revised diff removes the conflicting N key map!
> 
> I'm not super happy with the () for prev/next file, but I can't think of
> anything better right now.
> 
>  Two new sets of key maps are proposed:
>    ( - jump to the previous file
>    ) - jump to the next file
>    { - jump to the previous hunk
>    } - jump to the next hunk

In the past tog already did a secondary pass over the diff, reading
over all lines with getline() to calculate line offsets. (See the
function get_filestream_info() which was removed in
commit fe621944e83fe6367f7bff97128b4240a9cdc7c5).
For large diffs that are several metabytes in size this would slow down
the loading phase of the diff view considerably. Commits which trigger
this behaviour are those which update the clang compiler in the openbsd
base system.

Ideally, the diff code would produce hunk-offsets in addition to
the line offsets it is already producing, such that tog could
simply jump to those already known offsets once the diff result
has become available.

The diff code is managed in a separate repository, diff.git, intended
to be generally reusable outside of Got. I can give you commit access
there. The commit procedure we've been using is to commit changes to
files which originate in diff.git to diff.git itself first, and then
sync outstanding changes over to got.git in a single commit.