bug#8429: 24.0.50; regression: `flush-lines' does not flush all it should

["Drew Adams" <drew.adams@oracle.com>]

> > So the problem seems to be lazy highlighting. Unhighlighted 
> > text interferes with
> > search etc. because of the escape chars.
> 
> Yes, it sounds like flush-lines should retry when it fails to find a
> match, after lazy-highlighting the next portion of the buffer.

That doesn't sound like the right approach to me.

For one thing, the problem is not limited to `flush-lines'.  Any action on the
buffer text that gets thrown off by the added chars will be affected.  One of
the reasons to run `grep' in Emacs is to have a buffer of text to operate on.

For another thing, it's not clear that changing `flush-lines' in that way would
be appropriate for other use `flush-lines' contexts.

As I said, we might need to opt for letting the user initiate an editing mode.
Until now, `C-x C-q' was enough for that.  But maybe now more is needed.

But that's only if this bug cannot really be fixed in a way that gives back the
pre-regression behavior.

IOW, things worked well in Emacs 22 and 23; what was gained in losing this
behavior?  My guess is that the answer is performance: highlighting is no doubt
much faster because only what's shown gets highlighted.  That is important
(useful), no doubt about it.

If a tradeoff is needed and no better solution can be found, then I'd suggest a
command to make the buffer editable and completely highlighted.