unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>
Cc: 8429@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	[thread overview]
Message-ID: <1EA42FB8EA9B4526BF3D014AC2BB0CFE@us.oracle.com> (raw)
In-Reply-To: <83mxk4v3jj.fsf@gnu.org>

> > > 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.






  reply	other threads:[~2011-04-05 21:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-05 19:01 bug#8429: 24.0.50; regression: `flush-lines' does not flush all it should Drew Adams
2011-04-05 19:52 ` Eli Zaretskii
2011-04-05 20:14   ` Drew Adams
2011-04-05 20:36     ` Eli Zaretskii
2011-04-05 21:06       ` Drew Adams [this message]
2011-04-06  1:28         ` Stefan Monnier
2011-04-05 20:47     ` Eli Zaretskii
2011-04-05 21:15       ` Drew Adams
2013-02-02  0:32 ` Juri Linkov
2013-02-02  2:16   ` Drew Adams
2013-02-02 23:54     ` Juri Linkov
2013-02-03  0:30       ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1EA42FB8EA9B4526BF3D014AC2BB0CFE@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=8429@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).