@guy038 said: Do you have an explanation ? and I wrote: I think it has to be a bug It is, and it’s a fairly simple error in my logic. If a match ends at the end of the file (or the end of a selection or a span of marked text, if you’re searching within one of those), the search ends (or moves on to the next selection or span of marked text) without checking whether the expression can match null there. It will be fixed in the next release. Why adding |\z causes such strange behavior — in ICU even leading to new matches in the middle of the file — as yet I have no clue. The code supporting ICU search has the same logic error as the Regex search does, but there’s an additional oddity which seems to be built into ICU’s regular expression search. As best I can tell, it treats the circumflex (^) differently when it is the first element of the only alternative and in all other contexts. As an example, see the difference between marking ^\n (which matches nothing in Guy’s test text) and ^\n|Q (which matches the line feed at the end of each of the first nine lines). Note: I suggested using Mark to show this because Scintilla will not allow a selection to encompass only part of a line ending, so it’s less clear what is happening with Select or stepwise Find commands. The Search++ results list doesn’t have the option to show line endings — perhaps it should! — so Find All is also unclear. I’m not sure if this is expected behavior. ICU describes the circumflex as “Match at the beginning of a line” but, as far as I can find, says nothing about it behaving differently in different positions or expressions.