grep inside less?

less has very powerful pattern matching.  From the man page:

&pattern

Display only lines which match the pattern; lines which do not match the pattern are not displayed.  If pattern is empty (if you type & immediately followed by ENTER), any filtering is turned off, and all lines are displayed.  While filtering is in effect, an ampersand is displayed at the beginning of the prompt, as a reminder that some lines in the file may be hidden.

Certain characters are special as in the / command^†:

^N or !

Display only lines which do NOT match the pattern.
^R
Don't interpret regular expression metacharacters; that is, do a simple textual comparison.

____________
^† Certain characters are special if entered at the beginning of the pattern; they modify the type of search rather than become part of the pattern.

   (Of course ^N and ^R represent Ctrl+N and Ctrl+R, respectively.) 

So, for example, &dns will display only lines that match the pattern dns, and &!dns will filter out (exclude) those lines, displaying only lines that don't match the pattern.

It is noted in the description of the / command that

The pattern is a regular expression, as recognized by the regular expression library supplied by your system.

So

• &eth[01]  will display lines containing eth0 or eth1
• &arp.*eth0 will display lines containing arp followed by eth0
• &arp|dns  will display lines containing arp or dns

And the ! can invert any of the above.  So the command you would want to use for the example in your question is:

&!event text|something else|the other thing|foo|bar

Also use /pattern and ?pattern to search (and n/N to go to next/previous).

Building on orion's answer, the less(1) man page describes

/pattern

Search forward in the file for the N-th line containing the pattern.  N ^† defaults to 1.  The pattern is a regular expression, as recognized by the regular expression library supplied by your system.  The search starts at the second line displayed (but see the -a and -j options, which change this).

Certain characters are special if entered at the beginning of the pattern; they modify the type of search rather than become part of the pattern:

^N or !

Search for lines which do NOT match the pattern.
^E or *
Search multiple files.  That is, if the search reaches the END of the current file without finding a match, the search continues in the next file in the command line list.
^F or @
Begin the search at the first line of the FIRST file in the command line list, regardless of what is currently displayed on the screen or the settings of the -a or -j options.
^K
Highlight any text which matches the pattern on the current screen, but don't move to the first match (KEEP current position).
^R
Don't interpret regular expression metacharacters; that is, do a simple textual comparison.

____________
^† Commands may be preceded by a decimal number, called N in the descriptions …

   (Of course ^N and ^E, etc., represent Ctrl+N and Ctrl+E, etc.) 

It turns out that &pattern and /pattern work well together.  For example, the commands

• &!arp|dnsEnter
• /Ctrl+Kfail|fatal|fault|sd[a-z][0-9]Enter

typed in either order, will hide (exclude) all lines containing arp or dns (like grep -v), and then, in the remaining lines, highlight all occurrences of fail, fatal, fault, or anything that looks like the name of a SCSI device (sd[a-z][0-9]).  Note that lines that contain arp or dns, and also fail or any of the other danger words, will not be displayed.

Over the last few months, I have become somewhat enamoured of fzf.

In your case, as long as context is not needed (i.e., the equivalent of grep's -A, -B, or -C is not needed, and by the way, less's & also has the same limitation), then fzf is a very powerful tool.

Here's a silly example:

printf "%s\n" {aa,bb,cc}{dd,ee,ff}{gg,hh,ii} | fzf

If you run that, and play with inputs like aa | bb dd | ee !gg !hh and so on, you will quickly see what is happening.

Fzf's documentation on the | operator is sparse, but my best guess is it only applies to the terms immediately before and after, which means, in effect, that OR takes precedence over AND (which is implicit; all terms are AND-ed by default). But in most cases this should not be an issue, and things work out OK in my experience.

Give it a shot. I have found it surprisingly useful when it comes to browsing things when I am not really sure what I am looking for, and when context does not matter.