Other than for prediction by dictionary lookup, the assistant keeps the input text completely, without a gap. The structure comprising the data needs more storage than the plain text would need, in order to allow finding of associations fast. On the other hand, this is partly counteracted by some text compression. But the latter might hide some interesting location in the text. So, besides using some fundamental results, there are some design decisions which might be improved. A balance has to be aimed at, between the requirements of selection, order, and length of the proposed text pieces. The order is mainly according to the overlap of the end of input text to some older location, whose continuation is then being proposed. Concerning the length of the suggestion, I have tried to find a proper balance between the necessity for the user to shorten a suggestion too often, and to accept too short ones too often. A main problem with the selection is to come up to the user's expectation in this respect: When he has input a beginning part of a suggestion, he expects to see (at least) the rest as a new suggestion. This is sometimes made difficult by the compression; as mentioned above.
The assistant records text independently of the active application program. That is in principle useful, e.g if you use a textual command at one time and cite it at another time. But it is disadvantageous if a short input appears in not a lasting context. For instance, an application may, in special situations, interpret single letters or numbers as commands or decisions (e.g. to switch a view). The assistant cannot know this. The most disadvantageous consequence thereof seems to be an occasionally occuring slowness when repeatedly inputting a chacter several times. In practice, this will most likely happen with "space characters". This case is being avoided by the special handling of controls and spaces. A kind of positive side-effect. The role of spaces lies between that of normal text characters and of control characters. They are no normal text characters, but serve the production of space between e.g. words, since typewriter times. Distinct from control characters, a single space character between normal text characters will be kept by TypeHelp without further treatment.
Implementing this concept as an automatic appliance, one will of course not try to make a new electro-mechanical machine with visual and motor skills, but will try to use the operating system and keyboard functions. But trying to introduce an assistant as an additional instance between the user and normal application programs overtaking an operating task from the user, seems to require special means: For presenting the assistant's suggestions, we use a (small) window always in foreground; because it has to be visible like an editor window when the user is working with an application. For the user's commands to the assistant, we utilize the positioning functions of the numeric keypad, or the other arrow keys plus insert etc, changing their meaning. For this, and also for the assistant's listening to the user's text input to any application, we use the "hook" mechanism of Microsoft Windows.
The assistant records characters, not keystrokes: This has not been so clear in the past. But, generalized character sets need to use several keystrokes per character, and it seems appropriate to suggest the resulting characters by the assistant, but not sequences of key strokes. So we will try to support strictly those edit fields which are presented by programs which use the corresponding translation features offered by Windows, in future.