Copy link to clipboard
Copied
I've discovered that InDesign GREP behaves differently from standard regex engines when using the OR operator (|) combined with anchors (^ and $). This seems to be an undocumented behavior that differs significantly from what most regex documentation would suggest.
Text: ab ac bc Expected (standard regex): Matches "ab" at line start AND "c" anywhere Actual InDesign result: Only matches "ab" at line start
Text: ab ac bc Expected (standard regex): Matches "a" at line start AND "bc" anywhere Actual InDesign result: Only matches "a" at line start
Text: ab ac bc Expected (standard regex): Matches "a" at line start AND "bc" anywhere Actual InDesign result: Still only matches "a" at line start
Text: ab ac bca Expected (standard regex): Matches "a" at line end AND "bc" anywhere Actual InDesign result: Only matches "bc" (ignores the anchor completely)
Copy link to clipboard
Copied
I tried searching for
^a(b|c)
and this found “ab” or “ac” at the beginning of a pragraph. Is this what you are after?
Here I used GREP Style to highlight the affected text.
Copy link to clipboard
Copied
Thanks for the response, Scott! However, I think there might be a misunderstanding.
Your suggestion ^a(b|c) finds "ab" or "ac" at the beginning of a line, which is different from what I'm trying to achieve.
My issue is specifically with the OR operator behavior in InDesign GREP:
This differs from standard regex engines where both parts of the OR expression should be matched independently.
Question: Is this a known limitation of InDesign GREP's OR operator when combined with anchors? Or is there a way to achieve true OR behavior with anchors?
The core issue is that InDesign seems to interpret ^a|bc as ^(a|bc) instead of (^a)|(bc).
Copy link to clipboard
Copied
You’re absolutely correct, InDesign’s GREP engine does not treat the OR operator with anchors the same way standard regex does. The anchors are effectively ‘pulled out’ to cover the entire expression. A workaround is to use lookahead and lookbehind assertions to manually enforce anchoring, for example:
(^a)|(?<=.)bc
or
(^a)|bc
It is a known quirk. Adobe has never documented this fully, and most advanced InDesign GREP users learn it the hard way.
It’s not a bug as such, more of a design limitation in their simplified regex engine.
Copy link to clipboard
Copied
> Peter Kahrel's "GREP in InDesign" book notably omits any discussion of the OR operator
Well, that's not entirely true, there is discussion with examples in various places, and there is a section on alternatives, but it's true that you wouldn't find anything on the OR operator by looking at the table of contents. So that should have been clearer, thank you for the comment. But I wasn't aware of the problems with anchors and therefore there's no mention of them.
What you describe is clearly a bug. Did you report it (at https://indesign.uservoice.com)? If you did (or will do, please post the link here so that we can vote for it.
These days I don't think you can speak of 'standard regex'. Various versions have come about over the years -- see e.g. https://www.regular-expressions.info/tools.html and Friedl's (ageing) Mastering Regular Expressions. InDesign uses Boost's regex libraries, which are widely used. It's therefore not correct to say that InDesign uses a simplified regex engine. Adobe made errors integrating the Boost libraries, that's the problem.
Copy link to clipboard
Copied
Thank you so much for confirming this is indeed a bug. Your expertise gave me the confidence to submit a comprehensive bug report to Adobe.
I also want to apologize - I was trying to mention that the OR operator isn't covered in your book's table of contents, but I may not have expressed that clearly. I've attached the bug report link below.
Thank you again for your invaluable contribution to the InDesign GREP community.
Copy link to clipboard
Copied
Thanks for submitting the bug Report, I voted for it.
Find more inspiration, events, and resources on the new Adobe Community
Explore Now