unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Ari Roponen <ari.roponen@gmail.com>
To: Juri Linkov <juri@jurta.org>
Cc: 9679@debbugs.gnu.org
Subject: bug#9679: 24.0.90; After rgrep, next-error goes to the wrong line
Date: Fri, 07 Oct 2011 08:15:49 +0300	[thread overview]
Message-ID: <m3fwj58jqy.fsf@gmail.com> (raw)
In-Reply-To: <8739f6w35v.fsf@mail.jurta.org> (Juri Linkov's message of "Thu, 06 Oct 2011 18:27:56 +0300")

Juri Linkov <juri@jurta.org> writes:

> Thanks for the comprehensive test case.  I tried it but the second call
> goes into the line starting with "(mapcar #'string-to-number ...".

Hi,

I compared the behavior between the version with commits reverted and
not reverted.

In the reverted commits case, typing M-g M-p and M-g M-n goes to the
correct line and column, but highlights the whole line.

In the non-reverted commits case, typing those commands goes to the
wrong line but right column. The highlight seems to start at the end of
correct match and end at the cursor position.

I found something that may be relevant to the problem. These are the
values of *grep*-buffer's variable compilation-locs in both cases:

* Reverted commits case:

Value: #s(hash-table size 65 test equal weakness value rehash-size 1.5 rehash-threshold 0.8 data
	      (
	       ("./test.el")
	       (("./test.el" nil)
		nil
		(8
		 (nil 8 #1 #<marker at 251 in test.el> nil . t))
		(3
		 (nil 3 #1 #<marker at 89 in test.el> nil . t)))))

* Non-reverted commits case:

Value: #s(hash-table size 65 test equal weakness value rehash-size 1.5 rehash-threshold 0.8 data
	      (("Grep started at Fri Oct  7 07")
	       (("Grep started at Fri Oct  7 07" nil)
		nil
		(31
		 (nil 31 #1 nil nil)))
	       ("./test.el")
	       (("./test.el" nil)
		nil
		(8
		 (13 8 #1 #<marker at 258 in test.el> nil)
		 (7 8 #1 #<marker at 387 in test.el> nil . t))
		(3
		 (13 3 #1 #<marker at 96 in test.el> nil)
		 (7 3 #1 #<marker at 90 in test.el> nil . t)))
	       ("Grep finished (matches found) at Fri Oct  7 07")
	       (("Grep finished (matches found) at Fri Oct  7 07" nil)
		nil
		(31
		 (nil 31 #1 nil nil)))))

In the non-reverted commits case, The marker pairs seem to delimit the
matched text. The first pair (from 258 to 387) starts at the end of
correct match and goes too far. The second pair (from 90 to 96)
highlight correctly the first match.

I noticed that killing the buffer the markers use seems to fix the
problem:

1. Run the test case from the original bug report.
2. Kill the "test.el"-buffer
3. Type M-g M-p M-g M-n

Now the cursor is at the beginning of the match and the match is
highlighted correctly. The value of compilation-locs in *grep*-buffer is
also correct:

Value: #s(hash-table size 65 test equal weakness value rehash-size 1.5 rehash-threshold 0.8 data
	      (("Grep started at Fri Oct  7 07")
	       (("Grep started at Fri Oct  7 07" nil)
		nil
		(56
		 (nil 56 #1 nil nil)))
	       ("./test.el")
	       (("./test.el" nil)
		nil
		(8
		 (13 8 #1 #<marker at 258 in test.el> nil)
		 (7 8 #1 #<marker at 252 in test.el> nil . t))
		(3
		 (13 3 #1 #<marker at 96 in test.el> nil)
		 (7 3 #1 #<marker at 90 in test.el> nil . t)))
	       ("Grep finished (matches found) at Fri Oct  7 07")
	       (("Grep finished (matches found) at Fri Oct  7 07" nil)
		nil
		(56
		 (nil 56 #1 nil nil)))))

I guess the problem has something to do with those markers.

-- 
Ari Roponen





  reply	other threads:[~2011-10-07  5:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87r4uwybeh.fsf@gnu.org>
2011-10-06  6:14 ` bug#9679: 24.0.90; After rgrep, next-error goes to the wrong line Ari Roponen
2011-10-06 15:27   ` Juri Linkov
2011-10-07  5:15     ` Ari Roponen [this message]
2011-10-07  8:41       ` Ari Roponen
2011-10-07 15:20       ` Juri Linkov
2011-10-07 15:51         ` Ari Roponen
2011-10-07 16:36           ` Juri Linkov
2011-10-07 17:48             ` Ari Roponen
2011-10-08 16:30               ` Juri Linkov
2011-10-09  5:38                 ` Ari Roponen
2012-05-06  6:23                   ` Ari Roponen
     [not found]   ` <handler.9679.C.13363577086087.notifdonectrl.0@debbugs.gnu.org>
2012-05-13  6:39     ` bug#9679: acknowledged by developer (close 9679) Ari Roponen
2012-05-13  9:18       ` Chong Yidong

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=m3fwj58jqy.fsf@gmail.com \
    --to=ari.roponen@gmail.com \
    --cc=9679@debbugs.gnu.org \
    --cc=juri@jurta.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).