GNU bug report logs - #8429
move grep highlight from font-lock to process filter

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 8429 <at> debbugs.gnu.org
Subject: bug#8429: 24.0.50; regression: `flush-lines' does not flush all it should
Date: Tue, 5 Apr 2011 14:06:58 -0700

> > > Does it work if you copy the entire contents of the Grep buffer to
> > > another buffer?
> > 
> > No, same problem.
> 
> Well, as you yourself show, it is not the "same problem".

Same problem as the one I reported: `flush-lines' removes only the first few
matching lines.

> (And btw, there's no need to load cygwin-FOO.el to see the problem.
> Just "M-x grep RET "#" *.el" is enough.  It is also repeatable on
> GNU/Linux.)

I was clear that this is on Windows.  And on Windows there is no `grep' without
doing something besides emacs -Q.  Hence the recipe for Windows.

> > autorevert.el:368:;;;###autoload
> > autorevert.el:377:;;;###autoload
> > ...
> > 
> > As you can see, the problem seems to be that the string 
> > "###autoload" is not present as such.
> 
> Exactly!  Customize grep-highlight-matches to nil, and the problem
> goes away.

I hope you are saying that merely in order to lend support for the hypothesis
about the cause of the problem.  Doing that is certainly not a solution to the
problem.

> > Instead, escape characters are inserted between ## and #.
> 
> That's Grep in action, when we ask it to highlight matches in its
> output.  It does that by inserting ANSI escape sequences.

Yes, I know.  It also does that in Emacs 22 and 23, but without the bug.

If I had to guess in ignorance I'd say that it has to do with Emacs 24
highlighting only a screen at a time, instead of the whole buffer.  For the part
of the buffer that gets highlighted (so the escape chars are not apparent) there
is no problem.

> > I hope you will consider it a bug to be fixed.
> 
> Not me, but hopefully someone else.

You don't consider it a bug to be fixed, but you hope someone else will consider
it so?  What's that about?

Turning off highlighting to make the problem go away is not a solution.  This is
a regression and represents a real loss of functionality.

If a better solution is not found, we should at least give users knowledge of
how to make the buffer amenable to `flush-lines' etc.  Give them a command that
does whatever needs to be done.  A single command that makes the buffer editable
and fontifies everything would probably be enough, if it is well enough
advertised (e.g. in the `Grep' menu).  Again, that would be an acceptable
workaround only IF a real solution cannot be found.

I tried `font-lock-fontify-buffer', thinking that might be enough to do the
trick, but it did not.  It is font-locking that removes the escape-char markers,
but I guess the laziness of font-locking is still the problem, even with
`font-lock-fontify-buffer'.  The value of (font-lock-value-in-major-mode
font-lock-support-mode) in *grep* is `jit-lock-mode'.

It is common for users to operate on text in the buffer.  This bug makes the
*grep* buffer much less useful.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.