From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Emacs 22.2 release plans - request for a slight delay. Date: Fri, 7 Mar 2008 07:25:06 +0000 Message-ID: <20080307072506.GA1193@muc.de> References: <874pbwvmlv.fsf@stupidchicken.com> <87ir01krr7.fsf@stupidchicken.com> <20080306223857.GC3049@muc.de> <87lk4vv3s5.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1204873901 22608 80.91.229.12 (7 Mar 2008 07:11:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Mar 2008 07:11:41 +0000 (UTC) Cc: martin rudalics , Stefan Monnier , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 07 08:12:07 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 1JXWkR-0004pz-J1 for ged-emacs-devel@m.gmane.org; Fri, 07 Mar 2008 08:12:07 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JXWjt-0004wB-M4 for ged-emacs-devel@m.gmane.org; Fri, 07 Mar 2008 02:11:33 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JXWjp-0004w3-Kd for emacs-devel@gnu.org; Fri, 07 Mar 2008 02:11:29 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JXWjn-0004vf-1i for emacs-devel@gnu.org; Fri, 07 Mar 2008 02:11:29 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JXWjm-0004vR-UE for emacs-devel@gnu.org; Fri, 07 Mar 2008 02:11:26 -0500 Original-Received: from colin.muc.de ([193.149.48.1] helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JXWjm-000192-B9 for emacs-devel@gnu.org; Fri, 07 Mar 2008 02:11:26 -0500 Original-Received: (qmail 24990 invoked by uid 3782); 7 Mar 2008 07:11:21 -0000 Original-Received: from acm.muc.de (p57AF7575.dip.t-dialin.net [87.175.117.117]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Fri, 07 Mar 2008 08:11:18 +0100 Original-Received: (qmail 1589 invoked by uid 1000); 7 Mar 2008 07:25:06 -0000 Content-Disposition: inline In-Reply-To: <87lk4vv3s5.fsf@stupidchicken.com> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 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:91611 Archived-At: Hi, Yidong, On Thu, Mar 06, 2008 at 06:19:54PM -0500, Chong Yidong wrote: > > 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.] I meant to send that to the list, but must have hit 'r' instead of 'g' (in mutt). Apologies. > First off, could you check the patch into the trunk? Thanks. Yes, I'll do that this evening (European time). > 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? No. The CC Mode code is the same in Emacs-22 and the trunk. > Secondly, if memory serves, c-beginning-of-defun is not only used > interactively, but also for font-lock. Is this correct? I think so. I'll have a closer look later. > If so, is there a possibility that quitting from the paren-parsing > loop in this way will screw up font-lock? Yes, under the following conditions: (i) only when there is a K&R region (hence, only in C Mode, not C++, ObjC, ....); (ii) only when there are more than N (currently 20) paren/bracket pairs in the region (ignoring comments/strings/preprocessor lines). -- Alan Mackenzie (Nuremberg, Germany).