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

[Chong Yidong]

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?