From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: bug#636: Please fix before the release of 23.1 Date: Mon, 11 Aug 2008 19:01:24 +0000 Message-ID: <20080811190124.GB28138@muc.de> References: <877ibp4hh3.fsf@vorlon.ganneff.de> <871w1xfmsb.fsf@grepfind.mwolson.org> <87ljzj3oad.fsf_-_@grepfind.mwolson.org> <18590.45488.891078.545308@a1ihome1.kph.uni-mainz.de> <18590.47471.82980.734389@a1ihome1.kph.uni-mainz.de> <87ljz45xfj.fsf@stupidchicken.com> <18591.59359.40969.641357@a1ihome1.kph.uni-mainz.de> <87fxpb5xbn.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1218481886 19179 80.91.229.12 (11 Aug 2008 19:11:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Aug 2008 19:11:26 +0000 (UTC) Cc: Glenn Morris , Ulrich Mueller , Michael Olson , 636@emacsbugs.donarmstrong.com, emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 11 21:12:15 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KScoQ-0005Sf-Bh for ged-emacs-devel@m.gmane.org; Mon, 11 Aug 2008 21:12:14 +0200 Original-Received: from localhost ([127.0.0.1]:39329 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KScnT-0005LR-SI for ged-emacs-devel@m.gmane.org; Mon, 11 Aug 2008 15:11:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KSccA-0002Vz-FG for emacs-devel@gnu.org; Mon, 11 Aug 2008 14:59:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KScc9-0002Uw-M5 for emacs-devel@gnu.org; Mon, 11 Aug 2008 14:59:33 -0400 Original-Received: from [199.232.76.173] (port=51591 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KScc9-0002Ue-Bf for emacs-devel@gnu.org; Mon, 11 Aug 2008 14:59:33 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:2148 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KScc8-0002Gm-NR for emacs-devel@gnu.org; Mon, 11 Aug 2008 14:59:33 -0400 Original-Received: (qmail 78911 invoked by uid 3782); 11 Aug 2008 18:59:31 -0000 Original-Received: from acm.muc.de (pD9E5295F.dip.t-dialin.net [217.229.41.95]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Mon, 11 Aug 2008 20:59:28 +0200 Original-Received: (qmail 28548 invoked by uid 1000); 11 Aug 2008 19:01:24 -0000 Content-Disposition: inline In-Reply-To: <87fxpb5xbn.fsf@stupidchicken.com> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:102294 Archived-At: Hi, everybody! On Mon, Aug 11, 2008 at 12:30:04PM -0400, Chong Yidong wrote: > Ulrich Mueller 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).