[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: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:;;;[01;31m##[00m[K#autoload
> > autorevert.el:377:;;;[01;31m##[00m[K#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.