I haven't dug through the squiggle code quite enough to know it's current
implementation, but I think a flag on the specific squiggle might work in
combination with a dirty-word squiggle updater. So, you ignore a specific
word, and it's corresponding squiggle's flag, bIgnore, gets set. When the
squiggle's are drawn, obviously this one is not. Likewise, when evaluating
the current context, this word is considered squiggleless. Then, when this
region is dirtied due to editing, it reevaluates whether the squiggle, and
clears this flag (if it's still misspelled, obviously). This would have
the effect of adding a space to an ignored word, then removing said space,
and the "new" word, while the same as the original, would now be
considered misspelled, and thus squiggled-- which is exactly how Word
works.
Additionally, if I modified the dialog-based spell checking algorithm to
iterate through squiggles, rather than the whole document again, it gives
two additional benefits: 1) we don't have to look-up words again, they're
already marked, 2) if a squiggled word has bIgnore set, I'll just skip
over it, so that ignored words don't show up every time you spell check
(which is how Word workds).
This implies always squiggling text in the background (but just not
always showing the squiggles).
> Hmm. You mean they slow down editing to do the check, and then don't show
> the results except via that icon? (Sounds like strategy #2 above.)
Yeah, with squiggles always around we could do things like status bar
icons/messages.
> PS: This reminds me that we need to finish that old rewrite of the
> autospell code so that it just checks dirty words in response to editing,
> instead of doing the full destructive block-level recheck for each atomic
> edit.
This is sort of key to everything I've suggested above. Also, while the
squiggle code is being updated, it might be worthwhile trying to figure
out how to not squiggle new words before they're finished being typed.
Justin