While testing limit patch I came across not very intuitive search
behaviour which was introduced in Jun, by my patch 364ac6fd6 as unwanted
side effect:
https://marc.gameoftrees.org/thread/1661526335.M168509P13612Q2199.html

To illustrate, tog current got repo:

/foo
it will point to
2022-08-29 17132eaa

G (jump to the last commit)
n
it will jump back and point to next commit after 17132eaa, which contain
'foo':
2022-03-20 7a30b5cb

With inlined patch we trully respect currently selected commit and
start searching after it, so after we do 'G' we get 'no more matches'.

Thoughts?

(and sorry for the breakage of course)

diff refs/heads/main refs/heads/search
commit - 0c6ad1bc25c4e1d95a1173141a757137815ddaa8
commit + 7992253238d2dca2a9479a6bace062b5c25ee80d
blob - 81a72cd907757863416d7c2e4b5924f8413371a0
blob + 4d1990b9e43e3b65fbdf42dec6ebe9eeb69acf70
--- tog/tog.c
+++ tog/tog.c
@@ -2925,27 +2925,16 @@ search_next_log_view(struct tog_view *view)
 			entry = TAILQ_PREV(s->search_entry,
 			    commit_queue_head, entry);
 	} else if (s->matched_entry) {
-		int matched_idx = s->matched_entry->idx;
-		int selected_idx = s->selected_entry->idx;
-
 		/*
 		 * If the user has moved the cursor after we hit a match,
 		 * the position from where we should continue searching
 		 * might have changed.
 		 */
-		if (view->searching == TOG_SEARCH_FORWARD) {
-			if (matched_idx > selected_idx)
-				entry = TAILQ_NEXT(s->selected_entry, entry);
-			else
-				entry = TAILQ_NEXT(s->matched_entry, entry);
-		} else {
-			if (matched_idx < selected_idx)
-				entry = TAILQ_PREV(s->selected_entry,
-						commit_queue_head, entry);
-			else
-				entry = TAILQ_PREV(s->matched_entry,
-						commit_queue_head, entry);
-		}
+		if (view->searching == TOG_SEARCH_FORWARD)
+			entry = TAILQ_NEXT(s->selected_entry, entry);
+		else
+			entry = TAILQ_PREV(s->selected_entry, commit_queue_head,
+			    entry);
 	} else {
 		entry = s->selected_entry;
 	}