Re: address@hidden: Re: Emacs 22.2 release plans - request for a slight delay.]

[Alan Mackenzie]

Guten Morgen, Martin!

On Mon, Mar 17, 2008 at 08:33:13AM +0100, martin rudalics wrote:
> > For me (1.2 Ghz Athlon) C-M-a from EOB in .../src/lisp.h take ~1.5
> > seconds.  Previously, it was about 30 seconds.  That's an order of
> > magnitude speed up.

> I appreciate that.  The problem is that `add-change-log-entry' here
> still spends some 7 secs not finding anything useful with `point' on
> the line reading

> extern Lisp_Object safe_alloca_unwind (Lisp_Object);

> admittedly also because `add-change-log-entry' is rather stupid.

It calls c-beginning-of-defun 5(?) times whilst locating the name of the
current defun.  It does this because it has to jockey about, feeling out
whether it started _inside_ the function block, somewhere in the
function's header, etc.

I think the answer to this is to write the following in cc-cmds.el:

    (defun c-defun-name (&optional pos)
      "Return the name of the current function, or the one at POS.

    \"Function\" here means any named structure with a brace block, and
    \"current\" means the one surrounding point, starting or terminating at
    point.

    If there is no current function, return nil."
    .....
    )

That should reduce the above `add-change-log-entry''s time to ~ 1 second.

> > The problem is that it is impossible to decide without an unbounded
> > search whether
> >
> >     int foo [50] ;
> >     (char *) bar ;
> >
> > occurring at the outermost nesting level of a file.c is declaring global
> > variables or is a k&r region declaring function parameters.

> > I'd welcome suggestions as to how to speed it up, though.  I can't see
> > much alternative to what I've done (put a limit on 20 paren/bracket
> > pairs in a k&r region) unless I put in a "column 0 heuristic", something
> > I'd realy rather not do.

> I'm puzzled that (parse-partial-sexp (point-min) (point-max)) completes
> instantaneously here (without any paren/brackets limits).

Isn't there some sort of cacheing of p-p-s?  Anyhow, let us rejoice, not
puzzle, over this.  :-)

-- 
Alan Mackenzie (Nuremberg, Germany).