GNU bug report logs -
#8429
move grep highlight from font-lock to process filter
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Tue, 5 Apr 2011 19:08:02 UTC
Severity: minor
Found in version 24.0.50
Done: "Drew Adams" <drew.adams <at> oracle.com>
Bug is archived. No further changes may be made.
Full log
Message #23 received at 8429 <at> debbugs.gnu.org (full text, mbox):
> > 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.
This bug report was last modified 12 years and 135 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.