end-of-defun is fubsr. [Was: end-of-defun acts weirdly in c-mode]

[Alan Mackenzie]

address@hidden removed from the Cc:.]

Hi, Miles and Stefan!

On Tue, Feb 03, 2009 at 01:00:28PM +0000, Alan Mackenzie wrote:
> On Tue, Feb 03, 2009 at 12:29:06PM +0000, Alan Mackenzie wrote:
> > 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.

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

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.

It is IMAO a Bad Thing that \(beginning\|end\)-of-defun-function don't
have the same meaning modulo direction of travel.

I propose the following changes:
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.

2/- \(beginning\|end\)-of-defun-function should be trusted to do their
jobs.  These jobs should be defined to include moving to the next blank
line, to BOL, or over comments, and suchlike, as appropriate to the
major mode.  \(beginning\|end\)-of-defun should not tamper with the
position at all.

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

Alternatively, as a quick kludge, C-M-[ae] should be bound again to
c-\(beginning\|end\)-of-defun so as to make them work properly again.

-- 
Alan Mackenzie (Nuremberg, Germany).