Re: [db@zigo.dhs.org: 100% CPU usage in c-mode]

[Martin Stjernholm <mast@lysator.liu.se>]

Richard Stallman <rms@gnu.org> wrote:

> From: Dennis Björklund <db@zigo.dhs.org>
> Subject: 100% CPU usage in c-mode
> To: bug-gnu-emacs@gnu.org
> Date: Sat Mar 15 08:58:16 2003 +0100
/.../
> I use the emacs 21.2 that comes with rh8. Put the following c code
> in a .c file and load in emacs:
> 
> - --------------------------------
> void f()
> {
>     /*
>     {
> {
>     }
> */
>   }
> }
> 
> int main()
> {
>   g ();
> }
> - ---------------------------------
> 
> When I try to comment out the call to g in main(), then emacs freezes and
> uses 100% CPU. I guess it is some elisp code in c-mode having to do with
> matching parentheses or something. Comment out the line using // and it
> should trigger.

Thank you, I've verified this. I have now added a kludge in CC Mode to
avoid the infinite loop, but the real problem is in the low level
syntax routines in Emacs due to its treatment of open paren chars in
column zero (c.f. the section "Left Margin Paren" in the Emacs
manual). The case can be further minimized to this:

Open a buffer with C mode syntax installed. Insert the following:

{
/*
{
*/
}

Note that all five lines begin in column zero.

Put the point on the first '{' and call `forward-sexp'. The point
moves to the char following the '}', which is as expected. Now call
`backward-sexp'. The point doesn't move back to the first '{' but
instead to the second inside the comment.

It's the asymmetry between the forward and backward sexp movement that
caused a function in CC Mode to loop infinitely.

I'd prefer if the special treatment of open parens in column zero is
removed, or that it at least could be made configurable. CC Mode now
has other tools to handle this both correctly and more efficiently.
Besides, I think the cpu power commonly at hand today ought to be
enough to allow for more accurate solutions; it's not very nice to
demand of the user to format files certain ways just to be able to use
some ad hoc rules internally.