What to do about the Gemini's extra keys? Obviously we're gonna run a Gemini protocol emulator first, because it's the only machine I have access to, the company is friendly, and it's the cheapest currently available machine on the market (not counting the $795 Treal, I suppose, but it seems to be of limited virtue.) Do I want to be able to set left asterisk to quarantine and right asterisk to delete? What about the Extra keys? I seem mostly to be hitting them accidentally. Do we want to allow the option of inserting the automatic space before each new stroke or after each old stroke? How do we make steno output compatible with qwerty-style typing tests?

And sometimes you just feel like this.

I need to identify both the ways in which Plover clones the features of mainstream CAT software and the ways in which it fundamentally diverges from it. I'll try to pinpoint them and post them once they're in some sort of coherent shape.

If we truly want both steno-stroke memory and complete qwerty-style keyboard emulation, we'll have to take mouse clicks and other arbitrary jump tools into account. As long as navigation is accomplished by either steno or keyboard commands (whether with the arrow keys, j/k, or whatever), we can calculate the position of the cursor and whatever it's next to, and determine by that whether we're at the beginning of a sentence and should capitalize the first word, for instance. But what about jumps precipitated by searching or scanning? What about mouse clicks? It seems like a constant reckoning of "where are we, and what was entered into the location immediately previous to us, irrespective of when?" might be more practical than trying to do the math in a linear sequence. But how much will that slow us down? What about jumping between windows? If one window has a period at location [X] and we enter a new word into location [X+1] in another window, do we have to worry about it being capitalized? Not if we're careful, I think, but it could get complicated. Do all programs even have the capability to tell us where our cursor is? I'm thinking not; certainly not without translating formats. Can we do it by reading the lines/bytes in the file? But what about white space and other invisible markers that might throw us off? This is a puzzle.

Not much brewing; going through the book and digesting it all at a moderate rate. The most commonly recurring question in my brain seems to be: will the Plover steno dictionary format be comprised of actual Python dictionaries, with the steno strokes as keys and the definitions as values? Or will it need to be more complex, somehow? Will it be quick enough? Things to look into.

The other thing to consider is the timer. Eclipse doesn't work without it. DigitalCAT has an option to set the timer to zero, but it causes a lot of bugs, including improper stroke deletion and affixion. I can't stand the timer. Plover needs to process each stroke as quickly as possible, relate it to previous strokes (if applicable), and put it on the screen without delay. Then if the next stroke, combined with the previous, translates to something else, it should cleanly erase the old translation and display the new one. There should be no timer involved. I suppose this necessitates a buffer of at least 10 strokes (unlikely that any more than that would be linked together, though who knows; maybe a user-editable feature) to be held in memory. Each new stroke would prompt a reassessment of all 10, and the screen would be redrawn accordingly. This is the only way to make effective editing and CART display practical. But why have none of the other steno programs I've used been designed that way? Is it simply a legacy issue, or are there other obstructions? I hate having to flush Eclipse's buffer manually every few strokes. It's absurd.

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.

Transcribed from Moleskine:

1. Spits out raw steno when hooked up to Gemini. Not vertically, but left to right to fit screen, delineated by spaces. [I've changed my mind on this, and now think it should simply be |STENO| corresponding phrase, alternating next to each other, and made invisible or visible depending on what's used to view it -- like HTML markup.

2. Interfaces with simple lexicon (pref. rtf/cre) to translate strokes. Option of interlinear display with space between English words expanded to accommodate steno [again, I think this is misguided, because it further restricts steno output to Plover as a display/editing program rather than a translating-and-piping program], displayed centered below them. Toggle display of only steno, only English, and interlinear. No timer; provisional display appears immediately [with no confusing syntax designators like Eclipse has; option of toggling syntax in status window] and is replaced as new strokes alter the definition.

3. Editing, display customization, and keyboard emulation [I'm worried that keyboard emulation may have to be a more integral step; possibly the first thing through which everything is routed. Otherwise you might get the imperfect emulation of other steno programs]. Raw steno
can be piped to external applications as if by keyboard, as can translated steno. Separate command mode, or integrated?
4. How much Vim integration, and at what stage? [Should Plover be in two parts? One that loads on startup, like a keyboard driver, and allows for instant stenoing into any program with default dictionary settings, and limited options? And one that is more of an editing program, that allows customization and definition and all of that? Very hard to see where the line should be drawn. What it comes down to is that I want my steno keyboard to do everything my regular keyboard can do, with a minimum of fuss, but not giving up dictionary customization, and I want to be able to use Vim as easily as I do now with the regular keyboard. Maybe it means an invisible Plover background application and a Vim plug-in for steno-specific editing features.]


5. Guessing algorithms, metadictionary, etc. Plugins such as Typestriker, Bozzy, IRC. [Until we are able to duplicate Translation Magic, Plover, for all its virtues, will not be as practical as Eclipse, for all its flaws. High priority -- but, I fear, very complex.]

6. Optional status bar with stored (even after panic key) provisional definitions [this was what I was sketching out in the previous post], quarantine [unique among steno programs, as far as I know], one-stroke regex search. No dialogue boxes ever. [that might be a little extreme, but they're pretty damn annoying. Try to restrict everything to status bar, with silencing option]. Mouse support only a training wheel afterthought [Again, tone it down a little. A steno mouse emulator would be damn cool, especially for wearable applications. Might work, though -- one key of right bank, move mouse a little right, two keys, a little further, three keys further still, etc. I'd like to try it out.]

Invisible text (different levels of invisibility?), ability to write to file, suspend and resume definitions, taskbar.

Expand later when there's time.

Eclipse's Alt-R function (in the global window), which takes you to a dictionary entry and allows you to delete it from any of the dictionaries in which it appears, is invaluable. Duplicate it.

I've loaded the entry page as one of my home tabs, so I'm just going to use it as a brain dump for a while, until I've accumulated something worthwhile.

Eclipse bug: jumps to top of screen when new Speaker dialogue starts with a number. What could be causing this?

S + any entry in dictionary + S/Z (single stroke):

If it equals any entry in the dictionary: as written.
If it equals any entry in the dictionary that begins with S: as written, plus -s/-es. (If S,G,Z rule is on)
If it doesn't equal any entry in dictionary, but does when you strip S- and -S/Z off, translate as: "As [entry] as".

Text Processing in Python

The book came yesterday. I've been reading through the Appendix -- a review of Python. It's very well written; apparently the guy used to be a Humanities professor. I've gotten over my block with lambda and tuples and now understand them well enough. Classes, however, still stymie me. I'll keep working at it.

Link for my reference:

http://gnosis.cx/TPiP/

Arduino

Arduino is an open source language and hardware system. Might be very good to work with when building my own machine; certainly more practical than Flash. Not ideal for wearable use, perhaps, but I'll have to look into it. Might want to invest in classes at LEMUR, though the price is a bit steep. Probably should get Plover working first; this is a sidetrack. Still, something to file away.