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: Fri, 13 Feb 2009 11:08:19 +0000 Message-ID: <20090213110819.GA2975@muc.de> References: <20090203160941.GE1396@muc.de> <20090203185812.GH1396@muc.de> <20090204001445.GI1396@muc.de> <20090204133728.GB1049@muc.de> <20090204154427.GD1049@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1234522126 19192 80.91.229.12 (13 Feb 2009 10:48:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Feb 2009 10:48:46 +0000 (UTC) Cc: Andreas@mail.muc.de, Miles Bader , =?iso-8859-1?Q?R=F6hler?= , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 13 11:50:00 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 1LXvbb-0006wi-8b for ged-emacs-devel@m.gmane.org; Fri, 13 Feb 2009 11:49:11 +0100 Original-Received: from localhost ([127.0.0.1]:38175 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXvaH-0003Qg-82 for ged-emacs-devel@m.gmane.org; Fri, 13 Feb 2009 05:47:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXvaB-0003Qb-EY for emacs-devel@gnu.org; Fri, 13 Feb 2009 05:47:43 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXva8-0003QJ-SJ for emacs-devel@gnu.org; Fri, 13 Feb 2009 05:47:41 -0500 Original-Received: from [199.232.76.173] (port=59837 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXva8-0003QF-JJ for emacs-devel@gnu.org; Fri, 13 Feb 2009 05:47:40 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:3533 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 1LXva8-00007K-0H for emacs-devel@gnu.org; Fri, 13 Feb 2009 05:47:40 -0500 Original-Received: (qmail 37853 invoked by uid 3782); 13 Feb 2009 10:47:35 -0000 Original-Received: from acm.muc.de (pD9E23940.dip.t-dialin.net [217.226.57.64]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Fri, 13 Feb 2009 11:47:33 +0100 Original-Received: (qmail 3185 invoked by uid 1000); 13 Feb 2009 11:08:20 -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:109037 Archived-At: Hi, Stefan, On Thu, Feb 12, 2009 at 04:35:04PM -0500, Stefan Monnier wrote: > BTW, as you may have noticed I rewrote end-of-defun. It should fix the > asymptotic complexity issue (it still calls BOD-function typically > twice, tho). It still suffers an off-by-1 error. For example, load a C file and execute the following to make sure that the keys are appropriately bound: (define-key c-mode-base-map "\C-\M-a" 'beginning-of-defun) (define-key c-mode-base-map "\C-\M-e" 'end-of-defun) Now go to just after the end of a defun: void (foo) { return ; } ^ | Now do C-M-e. Point dribbles a bit of WS forward. ######################################################################### The problem here is that the generic end-of-defun-function moves to some arbitrary point in the WS between defuns. c-end-of-defun-function is typical of EOD-functions in this respect. If point also begins somewhere in the inter-defun WS, after calling BOD-function and EOD-function, it will land back at an arbitrary place in the same WS, which may be before, at, or after the starting point. We cannot, in the general case, deduce whether we started within or outwith a defun by this mechanism. > Stefan -- Alan Mackenzie (Nuremberg, Germany).