SpellingHistory

SpellingHistory: this maintains the history of attempted spelling corrections for the current command. We process each word separately, so each word has its own entry in the history.

The point of maintaining a history is that it allows us to backtrack if we decide that an earlier guess at a corrected word isn't going to result in a working command after all. If an earlier correction had other equally good options, we can go back and try the other options by unwinding the history.

class SpellingHistory : object

The indices of the words we've corrected so far. We keep track of the corrections we've made so that we don't try to further correct a word we've already corrected. (We *do* try multiple candidates per slot, but we do that by backtracking.)

The attempted correction stack. Each time we correct a word, we'll add a SpellingCorrection item to the stack. If we decide a correction didn't work after all (i.e., didn't yield a valid parsing), the stack lets us retract it and try a different correction candidate.

starting time (in GetTimeTicks time)

Check for spelling errors in a token list, and attempt automatic spelling correction. We'll scan the token list for a word that isn't in the dictionary. If we find one, and spelling correction is enabled, we'll attempt to automatically correct the error.

'toks' is the token list for the command line, and 'err' is the ParseError object indicating what error triggered the spelling check.

Returns a new token list if we correct a spelling error, nil otherwise.

no description available

have we made any corrections?

Note spelling changes between the original token list and the given token list.

Roll back spelling changes to the last one that actually improved matters. 'toks' is the latest token list, and 'err' is the parsing error that we encountered attempting to parse this token list.

If 'err' is a curable error, we'll leave things as they are. The curable error means that the token list is now well-formed, but is missing some information we need to actually execute it. Since it's well-formed, our spelling corrections must have made some kind of sense, so we'll assume they were correct.

If the error isn't curable, though, our spelling corrections didn't result in a working command. The way we pick candidate words tends to give us lots of false matches, so the fact that we didn't end up with meaningful syntax overall suggests that our guess for an individual word was a spurious match.

To determine what we keep and what we roll back, we look at whether a change improved the intelligibility of the command. There are basically three stages of intelligibility that we can distinguish: (1) completely unintelligible, (2) valid verb structure but unknown noun phrases, and (3) valid verb structure AND resolvable noun phrases.

We want to keep any attempted spelling corrections that successfully advanced us from one stage to the next, because the improved intelligibility is pretty good evidence that our corrections were in fact correct. We DON'T want to keep any corrections that didn't advance the process, because we can't tell if they actually helped. We're intentionally conservative about spelling correction, because spurious corrections are worse in an IF context than in most applications. In IF, a spurious correction could be a spoiler, by revealing the existence of a dictionary word too early in the game. To reduce spurious corrections, we only accept corrections that actually make the command more parseable.