Re: end-of-defun is fubsr.

[Alan Mackenzie <acm@muc.de>]

On Fri, Feb 13, 2009 at 11:22:48PM -0500, Stefan Monnier wrote:
> > ! This should move point to the next end of defun

> I don't think it's quite true.  It should really be "the end of the
> defun at point".  There might be a nearer EOD in a nested function.

Yes, there might be, and this might be the appropriate EOD.  (See
below.)

OK:  Maybe it should be

    This should move point to the \"next\" end of defun

, where "next" is to be interpreted appropriately for the nesting
strategy in use by the major mode.  For example, consider this fragment
of C++:

1   namespace baz
2   {
3       int bar = 666;
4                          // <==== Do C-M-e here.
5       int foo ()
6       {
7           return bar ;
8       }
9
......
42  }
43

Suppose in C++ Mode, the strategy for C-M-[ae] with nested defuns is "go
to the lexically next one, regardless of nesting depth" (which was
Martin Stjernholm's suggestion a few years back, and it's a good one).
Then starting at L4, C-M-e should go to L9.  However, (BOD-raw) will go
to L1, and "end of the defun at point" will be L43.  Whoops!

"Next"'s meaning should be at the discretion of the major mode author.

> > ! and return t on success, nil on failure.

> I don't think the return result is ever used as of now.  So I'd rather
> not document such a thing.

Emacs 22 and 21 end-of-defun return end-of-defun's result as
EOD-function's own return value, even if it wasn't documented.  We
shouldn't change this, surely?

> > ! It should not move further forward into any whitespace or
> > ! onto the next line.

> I used slightly different wording.

I don't see the previous wording specifying this at all.

> > ! It is called with no argument.
> > ! The function can assume that point is at the beginning of a defun
> > ! body or before the first defun in the buffer.")

> I prefer to keep the reference to BOD-raw, which makes this starting
> position much more precise.

Ah, OK.  But it shouldn't give the impression that the function may be
called ONLY after calling BOD-raw, and a bit less brusque than saying
"RTFS!!".

> > Another thing: in an elisp buffer, if (point-min) is in the middle of a
> > defun, C-M-e takes point to the next but one EOD.  CC Mode is just as
> > bad.  ;-)
> > Should end-of-defun perhaps widen the buffer around its machinations?

> Widening is not a good option, no.  Rather we may want to consider what
> should happen if a file starts in the middle of a defun.
> I am not going to lose too much sleep over this.

Nah, maybe not!  Anybody doing C-M-e can just get annoyed, he set the
narrrowing himself, and anybody using EOD in a program ought to widen
the buffer himself before manipulating it.

How about this, then:?

#########################################################################
(defvar end-of-defun-function #'forward-sexp
  "Function for `end-of-defun' to call.
This should move point to the \"next\" end of defun.  It should
not move further forward into any whitespace or onto the next
line.

It is called with no argument.  Its return value will become the
return value of `end-of-defun' when called from it.

The function can assume that point is at a position where
`beginning-of-defun-raw' could have left it, typically at the
beginning of a defun body or before the first defun in the
buffer.")
#########################################################################

>         Stefan

-- 
Alan.