Some features I wish I had during my experience expecting improvement from mixing steno+Qwerty

[lddllddl]

After about two years of regular use since learning the basics enough to type full sentences, I checked my speed on TypeRacer and found myself still much slower[30 to 40 WPM] on steno than on a Qwerty [60 to 70 WPM]. Steno has been much easier on my hands though, so I always preferred to use steno when writing plain English and actually switched to Qwerty when having to type fast!

I recently did some drills again and they definitely helped. However, I thought I would have improved during use, yet the improvement seemed too slow compared to dedicated drills. I had even modded my local copy of Plover to take notes of the last typed word on a special stroke, but I rarely bothered to practice on the accumulated word list either. Moreover, looking up the strokes then typing properly breaks the flow so much that I am often too lazy to look up the most efficient briefs.

As such I have thought of the following set of features which I believe would enable more effective learning from real use. I am able to implement the features myself (since they will cost much less time than all the practice I would have to do otherwise to increase my speed significantly above Qwerty). Meanwhile, I would also like to start some discussion on the proposed features so that I won't come with a sudden huge PR.

The general idea is to provide immediate visual feedback for the last typed word in whatever way (might extends to any identifiable token as well) or the last word failed to be typed (the most efficiently). A side effect would be being able to delete a whole word typed by a separate Qwerty keyboard.

Hypothetically, It would be the most desirable if the computer can display the next word that the typist intends to type after making an error, which is the case for interactive drills. Of course, the computer does not know what the typist intends to type next (otherwise there would be no need to type at all), whereas in an interactive drill the typist intends to type the word given by the computer, hence known by the computer.

If we let our imagination loose, the most probable next word(s) and how likely the typist will make an error could be predicted by an AI with contextual information gathered from past key sequence and all strings that have been recently displayed on the screen, which is surely too large a project to be practical. On the other hand, sticking with the current features, the typist can restrain themselves to always look up the correct or the most efficient strokes before continuing to type, which, even with shortcuts, is still orders of magnitude more time-consuming (and intrusive) than what an interactive drill provides.

So the closest thing to a drill-like experience in practical typing, as a reasonable extended feature set of Plover, that I was able to come up with, is as follows.

1. When typing, in addition to the emulated key presses, also pickup all system wide key presses not generated by Plover. Here's something I am not too sure about: from my experience with pynput, there seems to be no way to differentiate between a key event generated by the program itself and those come from outside of the program, at least under Xorg. The underlining working should be the same with the oslayer in Plover and pynput. I am not sure if oslayer could already deal with this problem or essentially some kind of de-duplication must be implemented.

2. Since we are also logging keyboard presses not processed by the steno engine (either by switching into/out of keyboard capture mode or by a separate device), we can consider a "combined keying sequence" which combines the output of Plover and separate key presses. For simplicity, any key combinations, navigation keystrokes (arrows, page-up/down, home/end), and the DEL key can be treated as special tokens in the sequence, exactly like what we use in the dictionary. However, some special treatment must be given to backspaces in a careful way, as it has been used extensively by the steno engine itself.

[still writing this up... which helps me to develop the details as well]

[user202729]

My opinion: Normally these things would be put into plugins.

Using Plover oslayer for capturing the keyboard keys (without suppressing it of course) would not be too difficult, as long as you stick to the capture-able keys.

It would also probably help (for the practice) to use one of the "cleaned-up" dictionaries so that the look up result will not be cluttered, and automatically convert the steno outline to pseudo-steno to make reading easier (at least for me.)