From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Martin Stjernholm Newsgroups: gmane.emacs.bugs Subject: Re: [db@zigo.dhs.org: 100% CPU usage in c-mode] Date: 23 Mar 2003 03:09:13 +0100 Sender: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Message-ID: <5b4r5uu94m.fsf@lister.roxen.com> References: Reply-To: bug-cc-mode@gnu.org NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1048385451 29022 80.91.224.249 (23 Mar 2003 02:10:51 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 23 Mar 2003 02:10:51 +0000 (UTC) Cc: rms@gnu.org Original-X-From: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 23 03:10:50 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18wuwj-0007Xx-00 for ; Sun, 23 Mar 2003 03:10:50 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18wuwp-0002CJ-01 for gnu-bug-gnu-emacs@m.gmane.org; Sat, 22 Mar 2003 21:10:55 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18wuwK-0001zG-00 for bug-gnu-emacs@gnu.org; Sat, 22 Mar 2003 21:10:24 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18wuw2-0001mS-00 for bug-gnu-emacs@gnu.org; Sat, 22 Mar 2003 21:10:09 -0500 Original-Received: from godzilla.roxen.com ([194.52.182.190] helo=mail.roxen.com) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18wuvG-0000mU-00; Sat, 22 Mar 2003 21:09:18 -0500 Original-Received: by mail.roxen.com (Postfix, from userid 52) id DE72F99D0; Sun, 23 Mar 2003 03:09:17 +0100 (MET) Original-Received: from lister.roxen.com (lister.roxen.com [194.52.182.147]) by mail.roxen.com (Postfix) with ESMTP id 0767E99CA; Sun, 23 Mar 2003 03:09:13 +0100 (MET) Original-To: bug-gnu-emacs@gnu.org In-Reply-To: Original-Lines: 63 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Original-cc: Dennis =?iso-8859-1?q?Bj=F6rklund?= Original-cc: bug-cc-mode@gnu.org X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.bugs:4644 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:4644 Richard Stallman wrote: > From: Dennis Bj=F6rklund > 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: >=20 > - -------------------------------- > void f() > { > /* > { > { > } > */ > } > } >=20 > int main() > { > g (); > } > - --------------------------------- >=20 > 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.