Another Bug ?? Broken Search ?? CC 2023

Text search engines work with internal pointers and consume characters while processing the stream. When a match is found, the pointer advances next to that match. And that's usually what users expect, in particular when replacements are involved. Breaking this rule would have serious consequences on many programs.

Now you can still prevent a search from consuming characters, using lookbehind/lookahead assertions. In your example, each 'o' preceded and followed by a space can still be captured (and changed) using a GREP pattern like (?<= )o(?= ).

Marc

That is the behaviour I expect and I wouldn't want it any other way. Consider the common practice of searching for double linebreaks and replacing with a single linebreak: the difference between find \r\r (finds 2 linebreaks) and \r\r+ (finds two or more linebreaks). This distinction would go away if the find function worked the way you imply.

Another way to put it is: the find function interpreter advances to the end of the last match each time; it does not start again from the beginning, or look behind (unless grep deliberately asks it to).

- Mark

I think you're expecting the space characters in the search to overlap.

In a string such as 'o-o-o-o-o-o' (with dashes standing in for spaces) there are only two examples of the string '-o-' as literals. Search doesn't start over and find the overlapping spaces for that.

Or did I miss your point?

That does not look right. GREPXtra finds them.