From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Emacs 22.2 release plans - request for a slight delay. Date: Thu, 06 Mar 2008 18:19:54 -0500 Message-ID: <87lk4vv3s5.fsf@stupidchicken.com> References: <874pbwvmlv.fsf@stupidchicken.com> <87ir01krr7.fsf@stupidchicken.com> <20080306223857.GC3049@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1204845738 18584 80.91.229.12 (6 Mar 2008 23:22:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Mar 2008 23:22:18 +0000 (UTC) Cc: martin rudalics , Stefan Monnier , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 07 00:22:45 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JXPQA-0007JQ-3c for ged-emacs-devel@m.gmane.org; Fri, 07 Mar 2008 00:22:42 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JXPPc-0002og-6u for ged-emacs-devel@m.gmane.org; Thu, 06 Mar 2008 18:22:08 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JXPPW-0002k7-Ti for emacs-devel@gnu.org; Thu, 06 Mar 2008 18:22:02 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JXPPS-0002b5-O6 for emacs-devel@gnu.org; Thu, 06 Mar 2008 18:22:01 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JXPPS-0002aW-EM for emacs-devel@gnu.org; Thu, 06 Mar 2008 18:21:58 -0500 Original-Received: from cyd.mit.edu ([18.115.2.24]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JXPPS-0002U2-4X for emacs-devel@gnu.org; Thu, 06 Mar 2008 18:21:58 -0500 Original-Received: by cyd.mit.edu (Postfix, from userid 1000) id 7949D4E401; Thu, 6 Mar 2008 18:19:54 -0500 (EST) In-Reply-To: <20080306223857.GC3049@muc.de> (Alan Mackenzie's message of "Thu\, 6 Mar 2008 22\:38\:57 +0000") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.91 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:91563 Archived-At: Hi Alan, > It's me again, causing trouble. ;-( It's OK. > I'm asking for a slight delay (perhaps over the weekend?) to fix a > serious bug in C mode, namely: > > Visit lisp.h, go to the end of the buffer, and do > M-x RET c-beginning-of-defun RET > > This is horrendously slow (~30 seconds). > > I've just had a look at c-beginning-of-defun, and I've narrowed the > fault down to `c-in-knr-argdecl', where the code laboriously trundles > back one paren pair at a time until it finds a "}" (or BOB). This is > clearly suboptimal in a region with several hundred consecutive > declarations without brace-blocks. There are ~900 consecutive > paren-pairs in the tail of lisp.h. > > So perhaps if I put the limit at 32, this will be safe for any > function not appearing in the Obfuscated C competition or > deliberately written to break editors. :-) > > This will probably be a "quick and easy" change, taking, perhaps, an > hour. However, it's probably worth while doing it calmly and carefully. > ;-) [Alan later sent a patch to me off-list.] First off, could you check the patch into the trunk? Thanks. I would like more information before we decide whether or not to check it into the branch and/or delay the pretest. First off, I just did a quick test, and the slowness also occurs in Emacs 22.1. It doesn't seem to be slower than in 22.1 (i.e. a regression), but I didn't time this precisely. Is there any reason to believe that the problem has gotten worse since 22.1, e.g. due to changes to CC mode since the 22.1 release? Secondly, if memory serves, c-beginning-of-defun is not only used interactively, but also for font-lock. Is this correct? If so, is there a possibility that quitting from the paren-parsing loop in this way will screw up font-lock?