bug#9679: 24.0.90; After rgrep, next-error goes to the wrong line

[Ari Roponen]

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