You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
continually load new words to meet time limit / scroll lines #6
Presently, when you pass -s to set a time limit, the test doesn't run for that amount of time. Instead, it runs until the you've typed all the words(which is 15 by default)
Solution
I really like 60 seconds typing tests and on something like monkeytype, the number of words isn't static - if you're typing fast, it increases the number of words automatically. There are 3 lines and as soon as you complete the 2nd line, a new line of words is added. So you never reach the last line.
This makes more sense to me.
Alternatives
However, I have no clue if doing that is feasible in a terminal. If it isn't, I think doing something similar to →(but without resetting the timer) would be nice.
Of course, I can do something like -s 60 -w 2000 but having so many words displayed at once makes it much more difficult for me to focus.
@TheTrio thank you for checking out thokr! This is an excellent idea, and would completely solve the performance issues (see context below) that comes from when users specify super long prompts. I had a similar idea of recreating the MonkeyType auto-scroll but honestly can't remember why I decided against it. I do know that at that point I wasn't aware of any performance concerns, so maybe that's why? Either way this seems like a great approach and know firsthand it would solve a number of problems. Are you interested in tackling this one with me? It's fine if not! I'm happy to assign it to myself and start work on it when things settle down for me!
Current performance concerns:
Here's a gif I made highlighting the problem. Keep in mind nobody in their right mind can actually type this fast, nor do I imagine anyone is requesting tests with word lengths this long, but it's still an important performance metric to consider. (basically rust is having to calculate what to draw on each and every keypress -- plus a 100ms interval if using a timed test) which slows down the processing significantly the longer the test goes on and the more there is to calculate.
Are you interested in tackling this one with me? It's fine if not! I'm happy to assign it to myself and start work on it when things settle down for me!
I really don't know that much rust, but I would love to give it a shot. I suppose the file to start hacking in is ui.rs?
Hey nice work! My main critique(s) would be that as you finish the first line you jump to the second line and stay there until the end of the test -- exactly as monkeytype does it. The only difference I might consider is that on monkeytype as you are approaching your last and final line, that last line jumps up to the second line (leaving no third line) and you finish. I think it might feel like a nice sense of satisfaction if you could actually see yourself finally jump out of the second line loop and make it to that third and final loop. There are a few other nitpicks I'm seeing in your branch, but nothing I we can't solve together! Why don't you open up a PR with it as is and we can workshop it! I think if you include #6 in the PR title it will auto link this issue. Also look out for a button in when creating the PR along the lines of Allow maintainer contributions or something, I believe that should let me add to the PR as well!
My main critique(s) would be that as you finish the first line you jump to the second line and stay there until the end of the test -- exactly as monkeytype does it
Yeah, that would definitely be a better experience. The only reason this looks the way it currently does is because I found it easier to implement.
There are a few other nitpicks I'm seeing in your branch, but nothing I we can't solve together!
Great! I'm sure I've written some pretty unidiomatic Rust, and would be happy to improve it!
Opened #26 which implements this: in -s timed mode, words now stream in continuously and the test ends on the timer instead of when you reach the end of the prompt. Long prompts scroll a fixed 3-line window so the layout stays put. Tests + a PTY run included — happy to adjust to taste if you'd like to land it. 🙂
This finally landed in #26, thanks to @hindriix! @TheTrio, thanks for the original idea and the early prototype way back when. Sorry it took so long. thokr -s 60 now really runs for 60 seconds.
Activity
jrnxf commentedon May 1, 2022
@TheTrio thank you for checking out thokr! This is an excellent idea, and would completely solve the performance issues (see context below) that comes from when users specify super long prompts. I had a similar idea of recreating the MonkeyType auto-scroll but honestly can't remember why I decided against it. I do know that at that point I wasn't aware of any performance concerns, so maybe that's why? Either way this seems like a great approach and know firsthand it would solve a number of problems. Are you interested in tackling this one with me? It's fine if not! I'm happy to assign it to myself and start work on it when things settle down for me!
Current performance concerns:
Here's a gif I made highlighting the problem. Keep in mind nobody in their right mind can actually type this fast, nor do I imagine anyone is requesting tests with word lengths this long, but it's still an important performance metric to consider. (basically rust is having to calculate what to draw on each and every keypress -- plus a 100ms interval if using a timed test) which slows down the processing significantly the longer the test goes on and the more there is to calculate.
TheTrio commentedon May 1, 2022
I really don't know that much rust, but I would love to give it a shot. I suppose the file to start hacking in is ui.rs?
TheTrio commentedon May 1, 2022
I have something like this presently
The code is here. I wanted to know if I'm in the right direction before making a PR
jrnxf commentedon May 1, 2022
Hey nice work! My main critique(s) would be that as you finish the first line you jump to the second line and stay there until the end of the test -- exactly as monkeytype does it. The only difference I might consider is that on monkeytype as you are approaching your last and final line, that last line jumps up to the second line (leaving no third line) and you finish. I think it might feel like a nice sense of satisfaction if you could actually see yourself finally jump out of the second line loop and make it to that third and final loop. There are a few other nitpicks I'm seeing in your branch, but nothing I we can't solve together! Why don't you open up a PR with it as is and we can workshop it! I think if you include
#6in the PR title it will auto link this issue. Also look out for a button in when creating the PR along the lines ofAllow maintainer contributionsor something, I believe that should let me add to the PR as well!TheTrio commentedon May 1, 2022
Yeah, that would definitely be a better experience. The only reason this looks the way it currently does is because I found it easier to implement.
Great! I'm sure I've written some pretty unidiomatic Rust, and would be happy to improve it!
Have also created a PR.
[-]Change displayed words dynamically[/-][+]continually load new words to meet time limit / scroll lines[/+]hindriix commentedon Jul 22, 2026
Opened #26 which implements this: in
-stimed mode, words now stream in continuously and the test ends on the timer instead of when you reach the end of the prompt. Long prompts scroll a fixed 3-line window so the layout stays put. Tests + a PTY run included — happy to adjust to taste if you'd like to land it. 🙂feat: continuous timed mode — stream words until the clock stops
feat: continuous timed mode, stream words until the clock stops (#26)
jrnxf commentedon Oct 29, 2026
This finally landed in #26, thanks to @hindriix! @TheTrio, thanks for the original idea and the early prototype way back when. Sorry it took so long.
thokr -s 60now really runs for 60 seconds.