As per the subject, don't repeat the (H)elp, log view limit (&),
and diff view (p)atch keymaps with a count modifier.

I didn't realise I had entered a count that was still active when I
entered '?' to bring up the help view; after closing the help view,
it immediately reopened. It took me a minute to realise what happened.

I thought I better look to see if any other keymaps should also be
single-fire and settled on these three. I can't see a valid use case
for repeating any of them and it can in fact be annoying in the case
of an unintended count modifier as that which led to this discovery.

ok?


commit 5e40d17444931c27c4984066760975f36b6a2430 (main)
from: Mark Jamsek <mark@jamsek.dev>
date: Sun Jan  5 12:25:04 2025 UTC

tog: don't apply count modifier to the H, &, p keymaps

It's annoying to have the help (H) and limit (&) keymaps repeatedly fire
after closing their respective views if accidentally preceded by a count
modifier, and doesn't seem like a valid use case. Similarly, writing N
patch files to /tmp is wasteful.

M  tog/tog.c  |  3+  0-

1 file changed, 3 insertions(+), 0 deletions(-)

commit - f9e081cffa503495ef67799c958ef44b04fa2caa
commit + 5e40d17444931c27c4984066760975f36b6a2430
blob - 24da169be687cc8f1d49741d9aab788cd5867273
blob + da3af395b2dbac57ee04e516108f32c3ee9ba1cd
--- tog/tog.c
+++ tog/tog.c
@@ -1868,6 +1868,7 @@ view_input(struct tog_view **new, int *done, struct to
 	case '?':
 	case 'H':
 	case KEY_F(1):
+		view->count = 0;
 		if (view->type == TOG_VIEW_HELP)
 			err = view->reset(view);
 		else
@@ -4899,6 +4900,7 @@ input_log_view(struct tog_view **new_view, struct tog_
 
 	switch (ch) {
 	case '&':
+		view->count = 0;
 		err = limit_log_view(view);
 		break;
 	case 'q':
@@ -7390,6 +7392,7 @@ input_diff_view(struct tog_view **new_view, struct tog
 		err = create_diff(s);
 		break;
 	case 'p':
+		view->count = 0;
 		err = diff_write_patch(view);
 		break;
 	default:


-- 
Mark Jamsek <https://bsdbox.org>
GPG: F2FF 13DE 6A06 C471 CA80  E6E2 2930 DC66 86EE CF68