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

Previous Next

Package: emacs;

Reported by: Ari Roponen <ari.roponen <at> gmail.com>

Date: Thu, 6 Oct 2011 06:15:02 UTC

Severity: important

Found in version 24.0.90

Done: Chong Yidong <cyd <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #29 received at 9679 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Ari Roponen <ari.roponen <at> gmail.com>
Cc: 9679 <at> debbugs.gnu.org
Subject: Re: bug#9679: 24.0.90; After rgrep, next-error goes to the wrong line
Date: Sat, 08 Oct 2011 19:30:12 +0300
>> mode: grep-mode, buffer: #<buffer *grep*>
>> col: 13, screen nil
>> col: 7, screen nil
>> col: 13, screen nil
>> col: 7, screen nil
>> mode: grep-mode, buffer: #<buffer *grep*>
>
> Grep finished (matches found)
> mode: grep-mode, buffer: #<buffer *grep*>
> col: 13, screen nil
> col: 7, screen nil
> col: 13, screen t
> col: 7, screen t
> mode: grep-mode, buffer: #<buffer *grep*>

Thanks, I can now reproduce this bug.  Its occurrence depends on the
frame's size.  When frame's dimensions are 80x43 with 43 lines or more, so
the first grep hit is visible in the *grep* buffer, then font-lock kicks in,
calculates absolute column positions, after that `compilation-next-error-function'
calculates relative column positions with markers for BOTH grep hits,
where the final position of the second grep hit is correct.

But when frame's dimensions are 80x42 with 42 lines or less, so the first
grep hit is not visible in the *grep* buffer, then fontification doesn't
start, and when you call `next-error', `compilation-next-error-function'
calculates column positions with markers only for the FIRST grep hit,
because the second grep hit is not fontified yet in the *grep* buffer.

The second grep hit gets processes later with `jit-lock-fontify-now'
that calls `compilation-internal-error-properties' and uses
`compilation-move-to-column' to calculate columns.

The problem is that `compilation-internal-error-properties' calculates
column marker positions differently than `compilation-next-error-function'.
Its markers have wrong positions as a result.

`compilation-next-error-function' is always called in the *grep* buffer
where it gets the buffer-local value of `compilation-error-screen-columns'
and keeps its value locally.  After that it visits the source buffer and
correctly calculates column positions using `compilation-move-to-column'.

`compilation-internal-error-properties' tries to do the same,
but uses a different algorithm.  It gets the global value
of `compilation-error-screen-columns' instead of buffer-local
from the *grep* buffer.

Another difference that contributes to the wrong position
is using:
	    (beginning-of-line (if end-line
				   (- line end-line -1)
				 (- loc marker-line -1)))
Contrary to this, `compilation-next-error-function' doesn't
call `beginning-of-line' after `compilation-move-to-column'
moves to the correct column.

Unfortunately, I can't fix this, because I don't understand
why there are two implementations of column position calculations.




This bug report was last modified 13 years and 9 days ago.

Previous Next


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