On Thu, Jul 14, 2022 at 01:37:07AM +1000, Mark Jamsek wrote:
> This implements the nG key map--functionally the same as vi(1) and
> less(1)--to navigate to line n in the diff and blame views.
> 
> As the diff view is a pager, we make nG behave like less(1) such that
> line n will be the first line on the page.
> 
> And because the blame view is more like an editor with navigation, we
> make nG behave like vi(1) such that line n is centered in the middle of
> the page--except for when n < view->nlines / 2. In this case, line
> n will be the nth line on the page (excluding the header).
> 
> The alternative is to make them both either place line n at the top
> [like less(1)] or the middle [like vi(1)] of the page. If we go that
> route, I'm partial to centering the line.

I would say centering makes sense for both diff and blame views.

Even though the diff view acts a bit like a pager, I don't see how you
could tell in advance which line of a diff to move to in order to find
something. There won't be any external index that would give you a
specific line number to move to. People will instead use search to
match a diff hunk header or the name of a function or struct.

However, since the diff view displays the total number of lines at the
top, nG could be used for operations that jump to 30% or 50% of the diff.
In which case centering on the target line makes more sense since that
will show context before and after the target line. Unlike prose text,
diffs are not always read linearly from top to bottom. At least I often
find myself jumping around in diffs to make sense of things.

> I didn't think it made sense to add this to the log, tree, and ref
> views; but if you think we should make it global, I'm happy to expand
> it.

nG might be interesting for log: "jump the to Nth commit". But it's
not very important.

> naddy suggested a while back that this makes the g key map somewhat
> redundant as 1G satisfies this use case, so we could be more like
> vi(1) and remove g; however, less(1) provides g so there's precedent for
> both. And given this only adds nG to two views, we probably want to keep
> g unless expanding nG to all views.

I'm also in favour of keeping 'g' since I use it :)