[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#5983: 23.1.96; compilation-next-error broken
From: |
Chong Yidong |
Subject: |
bug#5983: 23.1.96; compilation-next-error broken |
Date: |
Tue, 20 Apr 2010 11:37:38 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.96 (gnu/linux) |
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.