Skip to content

Add vim-style key bindings and timer scrubbing#29

Open
vizcay wants to merge 1 commit into
Bahaaio:mainfrom
vizcay:improved-shortcuts
Open

Add vim-style key bindings and timer scrubbing#29
vizcay wants to merge 1 commit into
Bahaaio:mainfrom
vizcay:improved-shortcuts

Conversation

@vizcay

@vizcay vizcay commented Jun 19, 2026

Copy link
Copy Markdown

Key binding changes

  • j / — new: decrease timer by 1 minute
  • k / — existing up arrow, now also bound to k (vim up)
  • h / — existing left/reset, now also bound to h (vim left)
  • l / — skip was previously s, now aligned to vim right (l + arrow key)

All four vim directional keys (h j k l) now map to the four timer controls, making the bindings consistent for vim users.

Timer scrubbing behaviour

Previously, extended the session by adding to duration. The new approach modifies elapsed instead, which correctly drives both the countdown display and the progress bar:

  • Decrease (j/): advances elapsed by 1 minute. Clamps to duration - 1s when less than a minute remains, so the timer reaches 00:01 and finishes naturally rather than getting stuck.
  • Increase (k/): retreats elapsed by 1 minute. Clamps to 0 when already near the start, restoring the full session time.

@Bahaaio

Bahaaio commented Jun 22, 2026

Copy link
Copy Markdown
Owner

Hey there, thanks for the PR :)

Changing skip from s to l and right arrow does indeed make sense for it to be more vim-like, I've thought about it before but didn't implement it for some reason.

But I have a few issues with how increase decrease keys are implemented in this PR:

Firstly, Increase is now limited to the initial duration only, which is not the behavior I want. I'd like to be able to extend it beyond initial duration when needed.

Secondly, this will inaccurate stats to the db, since adding extra time is currently implemented by subtracting from elapsed time rather than actually extending the session.

The same issue applies to decrease as well, since it will count more time than what was actually spent.

I've actually decided against adding a decrease key in the past in 5aace8bd, mainly because it adds calculation issues and edge cases. Looking at it again now though, I might reconsider it if implemented correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants