GNU bug report logs - #5983
23.1.96; compilation-next-error broken

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5983 in the body.
You can then email your comments to 5983 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: stephe <stephen_leake <at> stephe-leake.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1.96; compilation-next-error broken
Date: Tue, 20 Apr 2010 05:45:02 -0400

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.

I don't have a fix.

This same bug is in trunk (emacs version 24.0.50.2, bzr rev 99948)

In GNU Emacs 23.1.96.1 (i686-pc-linux-gnu, GTK+ Version 2.18.6)
 of 2010-04-20 on Shevek
Windowing system distributor `The Cygwin/X Project', version 11.0.10706000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t - e m a c s - b u g <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml
easymenu mml-sec password-cache mm-decode mm-bodies mm-encode mailcap
mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader
gnus-util netrc time-date mm-util mail-prsvr gmm-utils wid-edit
mailheader canlock sha1 hex-util hashcash mail-utils emacsbug tooltip
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd font-setting
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mldrag mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process font-render-setting gtk x-toolkit x
multi-tty emacs)

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Sam Steingold <sds <at> gnu.org>
Cc: 5983 <at> debbugs.gnu.org, stephe <stephen_leake <at> stephe-leake.org>
Subject: Re: bug#5983: 23.1.96; compilation-next-error broken
Date: Tue, 20 Apr 2010 11:37:38 -0400

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.

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

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#5983: 23.1.96; compilation-next-error broken
Date: Tue, 20 Apr 2010 09:26:42 -0500

On Tue, 20 Apr 2010 05:45:02 -0400 stephe <stephen_leake <at> stephe-leake.org> wrote: 

s> Now go to the next error: C-x `. Point should be on the line that prints
s> "missing paren", but it is on the previous line (the current line 5).

s> The problem seems to be in compilation-next-error. It has a mechanism
s> that sets markers based on the line/column info in the error messages,
s> assuming the file has not changed. It puts file mod timestamps in the
s> compilation error structure to record that this has been done, so it
s> doesn't get done again (after the buffer has changed). However, it
s> doesn't set the timestamp in every line, and when it gets to a line
s> without a timestamp, it processes the marker info again, which is wrong.

I thought this was fixed with bug#5620.

Ted

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Ted Zlatanov <tzz <at> lifelogs.com>, Sam Steingold  <sds <at> gnu.org>
Cc: 5983 <at> debbugs.gnu.org
Subject: Re: bug#5983: 23.1.96; compilation-next-error broken
Date: Tue, 20 Apr 2010 12:06:14 -0400

Ted Zlatanov <tzz <at> lifelogs.com> writes:

> On Tue, 20 Apr 2010 05:45:02 -0400 stephe <stephen_leake <at> stephe-leake.org> wrote:
>
> s> Now go to the next error: C-x `. Point should be on the line that prints
> s> "missing paren", but it is on the previous line (the current line 5).
>
> s> The problem seems to be in compilation-next-error. It has a mechanism
> s> that sets markers based on the line/column info in the error messages,
> s> assuming the file has not changed. It puts file mod timestamps in the
> s> compilation error structure to record that this has been done, so it
> s> doesn't get done again (after the buffer has changed). However, it
> s> doesn't set the timestamp in every line, and when it gets to a line
> s> without a timestamp, it processes the marker info again, which is wrong.
>
> I thought this was fixed with bug#5620.

Aha, looks like this was checked into the trunk only.  However, the fix
to Bug#5620 is quite drastic, and not suitable for the emacs-23 branch.

So, I have reverted the 2009-10-12 change to
compilation-next-error-function in the branch.  From my understanding,
the problem that this change was supposed to fix is relatively minor,
whereas the subsequent problem that it causes is quite serious.

Previous Next

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