I do think it's a little better, but I thought of this early on and decided not to pursue it because it adds an extra bit of complexity (or, at least, the way I was thinking about it it does). If you type "sru", you could match **S**pec**R**unner**U**tils just by using the existing algorithm but searching for specials rather than switching to contiguous matching right away. The problem comes in when you then search for "srun". When it starts dealing with the 'n', it will find that there are no specials that match after 'U'. There are also no contiguous matches after 'U'. So, it would actually need to backtrack further, going back to 'u' in the query and searching for contiguous matches at that point. By preferring contiguous matches after specials, I eliminate the backtracking part.

It seemed like too much additional complexity (at that point) to add to an algorithm that was producing good results.

Argh. So, as I was typing "eliminate the backtracking part" above, I thought of this case: MoonsunSum. Try to match "sun" with the current algorithm. It will match Moonsun**Su** and then fail on the 'm' and think it's not a match *at all*. I just wrote a test that demonstrates this. So, it turns out that the ability to backtrack is actually required.