I think that can't be done with a simple regular expression search. An automated search for building a report how often a string exists in one or more files requires a script.
Manually you can simple enter the string to search for in the Find dialog and press button Count All to get the information how often this string is found which can be a non regular expression or regular expression string.
Another method is to run Find in Files with searching in all open files or all files in a directory (tree) and look on the output in the output window or results edit window which lists all found lines containing the searched string, how often it is found in every file and the total number of found strings.
Best regards from an UC/UE/UES for Windows user from Austria
if UE's regex engine didn't have so many troubles with regexes that need to span multiple lines. If you throw this regex into a Perl script or an editor with a more robust regex engine, then this would work. UE uses the Boost regex library and (as far as I know) applies the regex not on the whole text but on individual lines. This fails on this regex.
Sorry.
Explanation:
(?s) makes the dot match newline characters \A matches the start of the file ((?!keyword).)* matches as many characters as possible up to the first occurrence of keyword keyword matches keyword ((?!keyword).)* matches as many characters as possible except for keyword \Z matches the end of the file
By using (?!.) as another way of saying "end of file" (after all, only at the end of the file you can be certain that it's impossible to match any further characters), you can construct a regex that doesn't need the \Z end-of-file anchor which UE doesn't support:
works *if* you place the cursor at the start of the file before starting the search. Curiously enough, UE seems to half-support the \A start-of-file anchor. It only matches at the start of the line the cursor is currently in, so if you're in the first line, \A behaves as it should. If you're on line 2, \A will match the start of line 2, though - this seems to be the same behavior caused by the line-based implementation of the regex engine that precludes the use of lookbehind assertions across newlines. Oh well. Better than nothing.