Re: Emacs 22.2 release plans - request for a slight delay.

[Alan Mackenzie]

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).