bug#5983: 23.1.96; compilation-next-error broken

[Chong Yidong]

Hi Sam, this bug is due to your change:

2009-10-12  Sam Steingold  <sds@gnu.org>

  * progmodes/compile.el (compilation-next-error-function): Fix the
  timestamps if the buffer has been visited before.

Reverting this change fixes the bug.  Could you double-check your work?
I have no idea what bug this change is trying to fix.

Thanks.



stephe <stephen_leake@stephe-leake.org> writes:

> Starting from `emacs -Q':
>
> open this C file:
>
> ------------
> int main (int argc, char *argv[])
> {
>
>    printf ("missing include\n");
>    printf ("missing paren";
>    return 0;
> } /* end main */
> /* end of file */
> ------------
>
> (note that it is missing a #include, and is missing a paren)
>
> Attempt to compile it:
>
> M-x compile
>
> Change the compile command to:
>
> gcc test.c
>
> This gives a list of compilation errors:
>
> -*- mode: compilation; default-directory: "/home/stephe/" -*-
> Compilation started at Tue Apr 20 05:25:38
>
> gcc test.c
> test.c: In function ‘main’:
> test.c:4: warning: incompatible implicit declaration of built-in function 
> ‘printf’
> test.c:5: error: expected ‘)’ before ‘;’ token
> test.c:7: error: expected ‘;’ before ‘}’ token
>
> Compilation exited abnormally with code 1 at Tue Apr 20 05:25:38
> ------------
>
> Go to the first error: C-x ` . point is now on the line that prints
> "missing include". Fix the problem by adding a line "#include <stdio.h>"
> at the top of the buffer. Now the line number in the next error message
> is wrong, but Emacs used to handle that by using markers appropriately.
>
> Now go to the next error: C-x `. Point should be on the line that prints
> "missing paren", but it is on the previous line (the current line 5).
>
> The problem seems to be in compilation-next-error. It has a mechanism
> that sets markers based on the line/column info in the error messages,
> assuming the file has not changed. It puts file mod timestamps in the
> compilation error structure to record that this has been done, so it
> doesn't get done again (after the buffer has changed). However, it
> doesn't set the timestamp in every line, and when it gets to a line
> without a timestamp, it processes the marker info again, which is wrong.