Is this algorithm modification valid?

[Avoi...@gmail.com]

This is a complex query.
The <software.eng> USEnet group seems not to handle such
general algorithm queries.

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?

==TIA.