Clearly the biggest problem with the split system is that of defining untranslates in situ. That's the top priority. It can probably be kludged to work in generic text editors, but I'm worried that it'll have the potential to get pretty ugly -- especially if we're jumping around the document and Plover has no way of seeing where we are with respect to what's on the text editor's screen. Also, setting * to delete last stroke (an indefinite number of times) is tricky unless you have a way of accessing previous strokes. I'll have to think on this.

I was thinking about it last night before falling asleep, and the more I ponder it, the more it makes sense: Plover itself should be only a translation/dictionary management engine, whose native state is as a draggable status bar with optional invisibility, which can spawn dictionary windows at command, but is otherwise extremely unobtrusive. Every command should be keyboard controlled, with a few optional dialogue boxes for those in need of hand holding.
User editable ini settings, with output options of 1) steno stroke echoed in section of status bar as written, but not stored; translation output to keyboard emulator, 2) steno stroke output to keyboard emulator along with translation in the form of markup, which can be visible or invisible according to the view settings of a yet-to-be-written text editor plugin (Stim at first, though it would be great if this could gain wide acceptance, like HTML), 3) steno strokes output invisibly to user specified file, translation output to keyboard emulator. Realtime linking of the two might be too complicated, but we'll see. Everything relating to translation should be coded into Plover. Everything relating to steno-specific editing should be coded into Stim, which will be a lower priority Vim plugin to aid in steno document composition and CART work.

I've been pretty good about brain dumping to this thing. Not much new this session, except that I should mention I'm 132 pages into Learning Python and really enjoying it. So far it's been review, but he's filled in a few gaps that confused me in the other tutorials I'd read. I'm looking forward to getting into the advanced portions, and after that I hope I'll be ready for Text Processing

Eclipse's problem with capitalization after a moich or a kpa -- it must be reading the invisible command and capitalizing it, rather than the actual first word in the sentence next to it. Then there's some sort of bot that passes through the page and corrects it a few seconds later. Weird kludge. Find a better method.

First step: steno emulator so I can start work on the project before getting the hardware drivers working?

William is concerned about speed of processing. I know 160,000+ plus entries in a dictionary is considerable, but even primitive steno software in the 80s was able to handle ~60,000 without blarfing. There must be a way to optimize it. Obviously guessing algorithms are trickier and will take still more speed, but we're not talking fancy graphics here. I will have to think of some way to obtain the numbers; my guess is modern computers won't balk at the sort of simple text searching functions we need, even if they're implemented in a high level language like Python. I just need to confirm that guess.

Scan for fingerspelled words.