Another Bug ?? Broken Search ?? CC 2023

[Robert at ID-Tasker]

Simple TextFrame with text:

" o o o o o o "

Try Find/Change and search for " o " - how many search results you'll get when you click FIND NEXT ?

Same problem when searching through Script ...

Or am I missing something ??

...

The same problem is with FireFox - screen from the current post:

WORD have the samme problem ??

[Pickory]

That does not look right. GREPXtra finds them.

[Robert at ID-Tasker]

There are spaces between "o"s.

[James Gifford—NitroPress]

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?

[Robert at ID-Tasker]

Yeah, maybe that's how it should work ...

[m1b]

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

[Robert at ID-Tasker]

Makes sense ... kind of ... but I'm looking for " o " - not "oo" - so every possible combination should be found and returned ?

[James Gifford—NitroPress]

Not every combination, not with Search. Maybe with variations of GREP.

But 'oooooooooooo' would only return four instances of 'ooo,' not... some factorial multiple.

[Robert at ID-Tasker]

Looks like it works as it supposed to work ...

If we have " o o o o o " - and then we start changing them to "-o-":

"-o-o o o o "

the 2nd " o " no longer exists as it's now "-o "

[Marc Autret]

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