unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* Re: [db@zigo.dhs.org: 100% CPU usage in c-mode]
       [not found] <E18umap-0003pg-00@fencepost.gnu.org>
@ 2003-03-23  2:09 ` Martin Stjernholm
  0 siblings, 0 replies; only message in thread
From: Martin Stjernholm @ 2003-03-23  2:09 UTC (permalink / raw)
  Cc: rms

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.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2003-03-23  2:09 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <E18umap-0003pg-00@fencepost.gnu.org>
2003-03-23  2:09 ` [db@zigo.dhs.org: 100% CPU usage in c-mode] Martin Stjernholm

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).