Re: end-of-defun is fubsr.

[Stefan Monnier]

>> > It's occurred to me that my "CVS" version wasn't actually clean.  Sorry
>> > for not checking this first.  I've downloaded a fresh copy of the CVS,
>> > and I'm building it at the moment.

>> Built.  Yes, I get the same thing as you, now.  Sorry for messing you
>> around.  I'll look into it.

> end-of-defun (in .../lisp/emacs-lisp/lisp.el) is buggy, at least when an
> end-of-defun-function has been defined:

> (i) After calling end-of-defun-function, e-o-d takes it upon itself to
> advance an arbitrary amount of whitespace/comments.  This is what you
> (Miles) were complaining about.

It should only move from "right after the closing }" to BOL 7.
Not "an arbitrary amount of whitespace".  Of course, there might be
a bug, but my guess is that your end-of-defun-function jumpts to BOL
7 rather than right after the brace.  So the problem is a disagreement
between the two.

> (ii) When point is BETWEEN two C functions (more precisely JUST AFTER
> the end of the previous function), C-M-e doesn't move over the next
> function.  This is because it gets its knickers in a twist, first
> calling BOD-raw, then EOD-function, trying to check if its succeeded
> yet, etc. .........   This is crazy!

This might be linked to the above problem.  For Elisp it seems to
work correctly.

> This mechanism is entirely unsuited to CC Mode.
> c-\(beginning\|end\)-of-defun have a very high setup (determining
> whether point is within a function's block, or header, etc.) and tear
> down (locating the start of a function's header) time, but is lightening
> fast zipping through brace blocks in between.  This high setup/teardown
> time has been the cause of several "it's too slow" bugs (e.g. for C-x 4
> a) in the last few years.

> The current implementation of end-of-defun is essentially calling
> c-end-of-defun AND c-beginning-of-defun in a loop, sometimes calling
> them twice in each iteration.  This is slow for large ARG.  It's crazy!
> To see this, go into buffer.c, and do

>     C-u 106 C-M-e

> .  On my box, this takes 20s.  By contrast, C-u 106 C-M-a takes about
> 0.5s.

I don't consider "C-u 106 C-M-e" as a common operation.

> Also, the semantics of end-of-defun-function have been completely
> changed (specifically, in lisp.el v1.82, 2007-11-26) so that it now has
> only a coincidental connection with what its name suggests.

Huh?  It hasn't completely changed.  Some details have changed to make
it easier to implement a simple end-of-defun-function, while making sure
that end-of-defun behaves consistently.
It was mostly a matter of fixing end-of-defun which was completely broken when
passed negative arguments.

> 1/- end-of-defun-function should be restored to its prior semantics, and
> additionally be passed the ARG argument in the same way as BOD-function.

Not sure about restoring the previous semantics.  But I could agree to
the additional ARG argument, which could even let it "take over" (so
beginning-of-defun-raw is not called in that case).

> 3/- end-of-defun should be restructured along the lines of
> beginning-of-defun.

I don't think that's a good idea.  The main reason is to deal with
languages that allow nested functions.


        Stefan