GNU bug report logs -
#5983
23.1.96; compilation-next-error broken
Previous Next
Full log
Message #8 received at 5983 <at> debbugs.gnu.org (full text, mbox):
Hi Sam, this bug is due to your change:
2009-10-12 Sam Steingold <sds <at> 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 <at> 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.
This bug report was last modified 13 years and 252 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.