[acm@muc.de: Re: Emacs 22.2 release plans - request for a slight delay.]

[Alan Mackenzie <acm@muc.de>]

----- Forwarded message from Alan Mackenzie <acm@muc.de> -----

Date: Thu, 6 Mar 2008 22:59:05 +0000
From: Alan Mackenzie <acm@muc.de>
To: Chong Yidong <cyd@stupidchicken.com>
Subject: Re: Emacs 22.2 release plans - request for a slight delay.

On Thu, Mar 06, 2008 at 10:38:57PM +0000, Alan Mackenzie wrote:
> Hi, Yidong,

[ .... ]

> I'm asking for a slight delay (perhaps over the weekend?) to fix a
> serious bug in C mode, namely:

>     Subject: Re: Unbearably slow editing in .h files
>     From: martin rudalics <rudalics@gmx.at> (and Stefan)
>     Date: Sat, 23 Feb 2008 23:51:34 +0100
>     Message-ID: <47C0A376.8080105@gmx.at>

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

> Even worse, c-in-knr-argdecl gets called twice, doubling the pain.

> Just how many paren/bracket pairs can there be in the K&R region of the
> header of a C function?  There is no absolute limit, but such a region
> will typically look less extravagant than this:

>    int foo (bar, baz, yuk)
>        int bar [] ;
>        int (*baz) (my_type) ;
>        int (*) (void) (*yuk) (void) ;
>    {

> , which has 7 such pairs.  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.
> ;-)

In fact, here's a provisional patch!  C-M-a seems to run fast enough with
it, even in .../src/lisp.h.


*** cc-engine.el~	2008-02-18 22:18:32.000000000 +0000
--- cc-engine.el	2008-03-06 22:55:31.263863296 +0000
***************
*** 6333,6339 ****
        ;; the searchable range.
        (let* ((macro-start (c-query-macro-start))
  	     (lim (max (or lim (point-min)) (or macro-start (point-min))))
! 	     before-lparen after-rparen)
  	(narrow-to-region lim (c-point 'eol))
  
  	;; Search backwards for the defun's argument list.  We give up if we
--- 6333,6340 ----
        ;; the searchable range.
        (let* ((macro-start (c-query-macro-start))
  	     (lim (max (or lim (point-min)) (or macro-start (point-min))))
! 	     before-lparen after-rparen
! 	     (pp-count-out 20))	; Max number of paren/brace constructs before we give up
  	(narrow-to-region lim (c-point 'eol))
  
  	;; Search backwards for the defun's argument list.  We give up if we
***************
*** 6355,6361 ****
  	;; {
  
  	(catch 'knr
! 	  (while t ; go round one paren/bracket construct each time round.
  	    (c-syntactic-skip-backward "^)]}")
  	    (cond ((eq (char-before) ?\))
  		   (setq after-rparen (point)))
--- 6356,6363 ----
  	;; {
  
  	(catch 'knr
! 	  (while (> pp-count-out 0) ; go back one paren/bracket pair each time.
! 	    (setq pp-count-out (1- pp-count-out))
  	    (c-syntactic-skip-backward "^)]}")
  	    (cond ((eq (char-before) ?\))
  		   (setq after-rparen (point)))


-- 
Alan Mackenzie (Nuremberg, Germany).


----- End forwarded message -----