Normally, when a thread's ThreadStart finishes, a thread is terminated and cleaned up. However, if a Dispatcher was created for that thread, the thread and Dispatcher-related resources will not be cleaned up. One such resource is a window handle, and if enough of these are leaked, the process will run out of valid handles and crash. In this case, the spell checker background thread is indirectly creating a Dispatcher, since it creates a WPF object (which creates a Dispatcher), and so needs to clean up the Dispatcher before the thread exits. This was identified by the Visual Studio watson process as causing ~1500 crashes.
…sues with using the C# colorizer to find comments / strings.
…ting too convoluted and had various bugs. The new method will likely be a bit slower, but should be better about what words to skip. Also introduced unit tests.
… it to each individual tagger. It's debatable whether this is correct on the abstract level, as it means URLs will never be checkable, but it works fine for now.
…ere words that end in 's have that portion excluded for the error span but not for the corrections. This means that words like "Hitchiker's" have "Hitchiker" underlined, offer "Hitchhiker's" as a suggestion, and the replace ends up with "Hitchhiker's's".
…se, the exception will crash VS.
…ining ALL CAPS at the end). Bumped to 2.19.
…ter the view has been closed.
…and what sub-sub versions are, and truncates it down to a single sub-version number.
…characters as lowercase characters.
…izable, and remove the tooltip that appears when you hover over spelling errors (it was just showing the word that was misspelled, again, so it wasn't useful).
…s a practical benefit (less pieces of words will be ignored, especially with the new logic around ignore words with numerals, underscores, and period) and possibly a performance benefit (in that fewer words may get spell checked).
…in the future, as it may end up ignoring certain documents that we don't want to ignore.
a) Normalize dirty spans before checking them. Without this, after typing, the same dirty span is checked over and over again, which is unnecessary. b) Don't ask for natural text tags until *after* normalization. This way, we only pay the cost once per normalized span, instead of basically once per change. c) Don't ask for natural text tags on the buffer changed listener (same change as (b), but different benefit). This keeps the possible performance penalties of natural text taggers from affecting typing.
…lDictionary that is basically in charge of the dictionary file. Without this, multiple buffers "own" the dictionary file and write to it (which seems to work), but ignoring a word in one file doesn't affect other files.
… underlying classifier sends out change events. Without this, inserting or removing a multi-line comment only affects the line the comment was inserted on, and not the entire commented in/out region.
1) Words that contain digits 2) "words" that look like they may be filenames. In the algorithm, this is just words that contain a "." followed by anything other than a "."; this may miss real misspellings (when the user forgets to put a space after a period), but file names are possibly more likely and the false positive is more annoying.