[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8429: 24.0.50; regression: `flush-lines' does not flush all it shoul
From: |
Drew Adams |
Subject: |
bug#8429: 24.0.50; regression: `flush-lines' does not flush all it should |
Date: |
Tue, 5 Apr 2011 14:15:33 -0700 |
> > 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.