Re: bug#636: Please fix before the release of 23.1

[Alan Mackenzie <acm@muc.de>]

Hi, everybody!

On Mon, Aug 11, 2008 at 12:30:04PM -0400, Chong Yidong wrote:
> Ulrich Mueller <ulm@gentoo.org> writes:

> >> (defconst foo
> >>   (let ((beginning-of-defun-function
> >> 	 (lambda (&optional arg)
> >> 	   (not (eq arg nil)))))
> >>     (progn
> >>       (beginning-of-defun 1))))

> >> (provide 'foo)

> > Calling beginning-of-defun will move point, right?

> > And since beginning-of-defun-function is essentially defined as a
> > no-op, point will just be moved to the beginning-of-line. (In fact,
> > eval-buffer on foo.el results in an infinite loop.)

> Aha, I see.

> So the question is, should we make the change to cc-defs.el, or (as
> suggested by Michael Olson) make the byte-compiler wrap around each
> variable definition with `save-excursion'?

The way I see it, it's a bug in `beginning-of-defun'.  The docstring
says that a non-nil `beginning-of-defun-function' finds the pertinent
place, but beginning-of-defun then moves point somewhere else.  I HATE
things that are ostensibly "helpful", but in reality are dumbing down,
and mainly just foul things up.

I would be in favour of NOT moving point after a BOD-function has done
its work.  However, I wouldn't campaign too hard about it, because ....

CC Mode should remain compatible with lots of Emacsen, including 21.n.
That means I'll have to modify CC Mode anyway.  So I will.

> Even with the latter solution, incorrectly written elisp in variable
> definitions can still create problems.  For example, `save-excursion'
> won't save us if the elisp runs `kill-buffer'.

Hey, that's an idea!  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).