Bug when searching up with regular expression pattern provider?

Hi Nick,

Actually not that is what I would expect to see.  It scans the character before the caret and sees if that character matches the pattern you give.  In your case it does, so it quits.  Then the next time it scans back one more character and sees a longer match from that point, and so on.

It looks like the Visual Studio find logic performs similarly from a quick test.

The current behavior seems to violate the fact that the regular expression + operator is a greedy operator.  This is a well understood semantic.  It should match as large a range as possible... 

From a high level, I would expect there to be a finite number of matches for a given search expression, determined by beginning from the start of the document and proceeding in document order.  Find next and find previous should then just cycle through those matches.  The matches should not change based on what direction you're searching.

Finally - it appears you tested with Visual Studio 2010 or earlier.  If you fire up Visual Studio 2012, you'll notice that it behaves differently - more closely to what I describe.  From the position of the cursor, it matches as large a range as it can.  It's still not exactly the behavior I describe above, but I could be convinced it's implementation is acceptable.

Hi Nick,

Yes I do see now how VS 2012 does all this differently than VS 2010.  I'm not sure I follow the VS 2012 logic but I do follow the VS 2010 logic, since it is essentially what we do as well.

The way we have it is that you start at a given caret offset.  We don't know anything about other matches.  We scan back a character and see if the find text matches at that point.  If so, it stops searching since a match was found.  Otherwise, it backs up another character and so on.  I don't like the idea much of backing up again even after a match to see if another larger match can be found because it is conceivable that there are certain regex scenarios that would require you to effectively do this all the way to the start of the document and doing full matches (some of which could scan forward hundreds or thousands of characters from each starting point), thereby killing performance and causing UI lockups.

I guess we can agree to disagree on which behavior is correct - although you seem to be talking more about how your algorithm works and less about correctness, or what a user would expect to see from a high level.  I can certainly understand the performance implications of trying to find the "correct" match with your current implementation.

Thanks for your time.

Hi Nick,

I agree with you that what you expect is the "correct" way to do it.  But I'm just saying that I am hesitant to change our current logic to what I described because of the possible very negative performance impacts.