[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#636: Please fix before the release of 23.1
From: |
Alan Mackenzie |
Subject: |
bug#636: Please fix before the release of 23.1 |
Date: |
Mon, 11 Aug 2008 19:01:24 +0000 |
User-agent: |
Mutt/1.5.9i |
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).
- bug#636: Please fix before the release of 23.1, (continued)
bug#636: Please fix before the release of 23.1, OFFICE ZERO, 2008/08/10
bug#636: Please fix before the release of 23.1, Ulrich Mueller, 2008/08/11
bug#636: Please fix before the release of 23.1, Michael Olson, 2008/08/11
bug#636: Please fix before the release of 23.1, Chong Yidong, 2008/08/11
bug#636: Please fix before the release of 23.1,
Alan Mackenzie <=