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: end-of-defun is fubsr. Date: Sat, 14 Feb 2009 18:00:30 +0000 Message-ID: <20090214180030.GA4679@muc.de> References: <20090204133728.GB1049@muc.de> <20090204154427.GD1049@muc.de> <20090213110819.GA2975@muc.de> <20090213164210.GC2975@muc.de> <20090213185756.GD2975@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1234633198 7989 80.91.229.12 (14 Feb 2009 17:39:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Feb 2009 17:39:58 +0000 (UTC) Cc: emacs-devel@gnu.org, =?iso-8859-1?Q?R=F6hler?= , Miles Bader To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 14 18:41:13 2009 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 1LYOVr-0002ir-Vr for ged-emacs-devel@m.gmane.org; Sat, 14 Feb 2009 18:41:12 +0100 Original-Received: from localhost ([127.0.0.1]:37076 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LYOUX-0006js-KV for ged-emacs-devel@m.gmane.org; Sat, 14 Feb 2009 12:39:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LYOUQ-0006eM-2A for emacs-devel@gnu.org; Sat, 14 Feb 2009 12:39:42 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LYOUP-0006d6-A8 for emacs-devel@gnu.org; Sat, 14 Feb 2009 12:39:41 -0500 Original-Received: from [199.232.76.173] (port=39582 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LYOUO-0006cV-Tb for emacs-devel@gnu.org; Sat, 14 Feb 2009 12:39:40 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:4610 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 1LYOUO-0004eL-BV for emacs-devel@gnu.org; Sat, 14 Feb 2009 12:39:40 -0500 Original-Received: (qmail 11824 invoked by uid 3782); 14 Feb 2009 17:39:35 -0000 Original-Received: from acm.muc.de (pD9E52544.dip.t-dialin.net [217.229.37.68]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Sat, 14 Feb 2009 18:39:33 +0100 Original-Received: (qmail 14448 invoked by uid 1000); 14 Feb 2009 18:00:30 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: 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:109068 Archived-At: 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.