Editors commonly have Search&Replace facilities, but one's
that I know, handle only one or a few lines.   The application
that I need it for, should also handle a small subset of regular
expressions, eg. ignore whiteChars and "["%{%}"]" where
% is a decimal-digit. So these two lines should match:
"   description of `lynx-link` [43] spaces     may vary "
" description of `lynx-link` [961]      spaces may vary "

Typical the user will edit a 4'000 line text file, where,
when a block of RepeatedGarbage  of say 50 lines is
recognised; the GarbageBlock can be 'marked' and
`DeleteAllFurtherSuchBlocks` initiated
[with he above described match-relaxation].

The intention is to extend the existing ETHO 'slik editor'
which does only exact matches and where the
search/replace is too small.  

My initial approach to this task via GNU awk proposed
copying out the DeleteBlock to a separate file which is
usefull for awk, and removes the problem of the
too-small search/replace buffer.

One search/replace with full Regular-expression-matching
that I tested, gave out-of-memory-errors with moderately
large blocks.  And I suspect that Regular-expression-matching
is very expensive.

Would the following trick, likely work?
The heart of <search for matching block> MUST be a
<compare&stepChar>, where <compare> will be a simple:
IF InFile[i]=DeleteBlok[j]. {or '==' for curly languages}

Now if you factor-out this comparison-test with its matching
pre/post-increment, into a boolean-function:
     CompareStep(InFile[i], DeleteBlok[j]): boolean;
if that's OK, then simple extentions to this function to handle
the 2 matching-relaxations described above, avoids
use of a full/complex RegexMatcher. And more
comparison-relaxations can easily be added later,
as needed.

Would you expect this to work?