continually load new words to meet time limit / scroll lines

[TheTrio]

Problem

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.

[jrnxf]

@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]

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?

[TheTrio]

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]

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!

[TheTrio]

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!

Have also created a PR.