Bug when searching up with regular expression pattern provider?

SyntaxEditor for WPF Forum

Posted 7 years ago by Nick Beer - National Instruments
Version: 12.2.0570
Platform: .NET 4.0
Environment: Windows 7 (64-bit)
Avatar

Hello -

I'd like to report what I think is a bug with the ITextSnapshot.FindNext implementation when searching up and using the regular expression pattern provider.  This bug can easily be seen in the sample browser:

  1. Run the sample browser and go to the "Search - Custom Pattern Provider" sample.
  2. In the 'Find what:' box, type [est]+
  3. Ensure regular expression is the selected search type, and 'Search Up' is ticked.
  4. Replace all the text in the syntax editor document with 'test'
  5. Move the cursor to the end of the text in the syntax editor document
  6. Press the find next button, and notice that only the last 't' in 'test' is highlighted.
  7. If you press it again, you'll now see that 'st' is highlighted, and so on, until all of 'test' is highlighted.

I would expect for the entire text ('test') to be highlighted the first time I press the find next button.

Do you agree that this is a bug?

- Nick

Comments (5)

Answer - Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 7 years ago by Nick Beer - National Instruments
Avatar

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.

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 7 years ago by Nick Beer - National Instruments
Avatar

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.

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

The latest build of this product (v2019.1 build 0683) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.