ttyper v2

[max-niederman]

Motivation

I first created ttyper over one weekend as a simple proof of concept. I never foresaw myself continuing to develop the project, let alone that so many others would use it, so I went with the easy route: a suboptimal UI using seperate input and prompt sections and a dead-simple logic implementation which pretty much only works for short passages of English.

Ultimately, I want ttyper to be at parity with monkeytype, the gold standard of typing tests. Version 2 will not be enough to achieve that, but I want to do a complete rewrite with a focus on getting the core test UX up to par and improving support for languages which don't use the Latin script.

Goals

Improved Test UI

The test UI should be updated to unify the input and prompt sections, with all mistakes shown inline with the prompt. Only a few lines of the prompt should be shown to the user at once, like with monkeytype.

Another UI I'm considering is "conveyor mode", where only one line is shown and the user's cursor is fixed in place as the prompt moves around it.

Better Language Support

Right now, ttyper tests are made up of a list of words, which are assumed to be seperated by spaces. This works pretty well for languages which use the Latin script, and it works passably for most programming languages, but it is completely wrong for nearly all other languages.

Thankfully, with the new test UI, understanding word boundaries is much less important. Instead of defining when the input box is reset, word boundaries will be used only for line wrapping. v2 should implement word boundary detection (i.e. lexical analysis) for common languages, but fall back to wrapping at any character (extended grapheme cluster to be specific) if the language isn't known.

Improved Dictionaries

Currently, both English and German have multiple word lists which vary only in the number of included words. The duplication isn't ideal, and it's particularly bad that the choices are inconsistent from language to language. Monkeytype also has this problem.

To solve this, ttyper will have an option to cut off a dictionary at an arbitrary number of words. Also, it might be good to add frequency weighting as discussed in #2.

Result Saving

It should be possible to save test results. See #28.

Quotes

Shipping quote sets along with wordlists and/or pulling quotes from an HTTP API would make it much easier to do more realistic tests. I'm not totally sure about pulling from the internet, since I want ttyper to remain adherent to the Unix philosophy by staying as simple as possible.

Integration Tests

v1 has been plagued by a variety of reccuring crashes which could have easily been caught by integration tests. For v2, there should be integration tests which replay keystrokes, ensure that ttyper doesn't crash, and check the generated result file for correctness.

Streaming Support

Right now, ttyper loads the entire test content into memory before beginning the test. For v2, it should be possible to do tests that are larger than the system memory, and for the user to start typing before the entire file has been read (e.g. because it's still being downloaded).

Plans

I plan to do a complete rewrite, and I intend to drop the dependency on tui-rs. There are definitely some things that are convenient in it, but ultimately tui-rs's widget system just doesn't conveniently map on to the new UI. Instead, I plan to use crossterm directly.

If you're interested in helping out or have any comments, please reply here.

[besselfunct]

As a stretch goal, I think it would be nice to parse epubs as input. typelit is great, but it would be nice to have something local that would provide similar functionality. This library appears to offer epub parsing functionality, but it would be necessary to introduce some kind of log so that a user could resume at the previous location. bk also seems to have the epub rendering in the terminal handled already.