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: end-of-defun is fubsr. [Was: end-of-defun acts weirdly in c-mode] Date: Tue, 3 Feb 2009 16:09:42 +0000 Message-ID: <20090203160941.GE1396@muc.de> References: <20090202202703.GB11077@muc.de> <20090203105035.GB1396@muc.de> <20090203122906.GC1396@muc.de> <20090203130028.GD1396@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1233676248 8760 80.91.229.12 (3 Feb 2009 15:50:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Feb 2009 15:50:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: Miles Bader , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 03 16:51:53 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 1LUNYk-0006c5-Mw for ged-emacs-devel@m.gmane.org; Tue, 03 Feb 2009 16:51:37 +0100 Original-Received: from localhost ([127.0.0.1]:55867 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUNXR-0002bd-Hz for ged-emacs-devel@m.gmane.org; Tue, 03 Feb 2009 10:50:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUNXN-0002bY-4J for emacs-devel@gnu.org; Tue, 03 Feb 2009 10:50:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUNXK-0002bM-F7 for emacs-devel@gnu.org; Tue, 03 Feb 2009 10:50:08 -0500 Original-Received: from [199.232.76.173] (port=35229 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUNXK-0002bJ-Bp for emacs-devel@gnu.org; Tue, 03 Feb 2009 10:50:06 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:3357 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 1LUNXJ-0000iG-JZ for emacs-devel@gnu.org; Tue, 03 Feb 2009 10:50:05 -0500 Original-Received: (qmail 73045 invoked by uid 3782); 3 Feb 2009 15:50:03 -0000 Original-Received: from acm.muc.de (pD9E51F3C.dip.t-dialin.net [217.229.31.60]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Tue, 03 Feb 2009 16:50:01 +0100 Original-Received: (qmail 24207 invoked by uid 1000); 3 Feb 2009 16:09:42 -0000 Content-Disposition: inline In-Reply-To: <20090203130028.GD1396@muc.de> 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:108685 Archived-At: [bug-cc-mode@gnu.org removed from the Cc:.] Hi, Miles and Stefan! On Tue, Feb 03, 2009 at 01:00:28PM +0000, Alan Mackenzie wrote: > On Tue, Feb 03, 2009 at 12:29:06PM +0000, Alan Mackenzie wrote: > > It's occurred to me that my "CVS" version wasn't actually clean. Sorry > > for not checking this first. I've downloaded a fresh copy of the CVS, > > and I'm building it at the moment. > Built. Yes, I get the same thing as you, now. Sorry for messing you > around. I'll look into it. end-of-defun (in .../lisp/emacs-lisp/lisp.el) is buggy, at least when an end-of-defun-function has been defined: (i) After calling end-of-defun-function, e-o-d takes it upon itself to advance an arbitrary amount of whitespace/comments. This is what you (Miles) were complaining about. (ii) When point is BETWEEN two C functions (more precisely JUST AFTER the end of the previous function), C-M-e doesn't move over the next function. This is because it gets its knickers in a twist, first calling BOD-raw, then EOD-function, trying to check if its succeeded yet, etc. ......... This is crazy! This mechanism is entirely unsuited to CC Mode. c-\(beginning\|end\)-of-defun have a very high setup (determining whether point is within a function's block, or header, etc.) and tear down (locating the start of a function's header) time, but is lightening fast zipping through brace blocks in between. This high setup/teardown time has been the cause of several "it's too slow" bugs (e.g. for C-x 4 a) in the last few years. The current implementation of end-of-defun is essentially calling c-end-of-defun AND c-beginning-of-defun in a loop, sometimes calling them twice in each iteration. This is slow for large ARG. It's crazy! To see this, go into buffer.c, and do C-u 106 C-M-e . On my box, this takes 20s. By contrast, C-u 106 C-M-a takes about 0.5s. Also, the semantics of end-of-defun-function have been completely changed (specifically, in lisp.el v1.82, 2007-11-26) so that it now has only a coincidental connection with what its name suggests. It is IMAO a Bad Thing that \(beginning\|end\)-of-defun-function don't have the same meaning modulo direction of travel. I propose the following changes: 1/- end-of-defun-function should be restored to its prior semantics, and additionally be passed the ARG argument in the same way as BOD-function. 2/- \(beginning\|end\)-of-defun-function should be trusted to do their jobs. These jobs should be defined to include moving to the next blank line, to BOL, or over comments, and suchlike, as appropriate to the major mode. \(beginning\|end\)-of-defun should not tamper with the position at all. 3/- end-of-defun should be restructured along the lines of beginning-of-defun. Alternatively, as a quick kludge, C-M-[ae] should be bound again to c-\(beginning\|end\)-of-defun so as to make them work properly again. -- Alan Mackenzie (Nuremberg, Germany).