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: movement bindings in c-mode Date: Mon, 23 Jun 2008 14:13:34 +0000 Message-ID: <20080623141334.GA7132@muc.de> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1214229051 10233 80.91.229.12 (23 Jun 2008 13:50:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Jun 2008 13:50:51 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 23 15:51:35 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 1KAmRq-0008Cw-G3 for ged-emacs-devel@m.gmane.org; Mon, 23 Jun 2008 15:51:10 +0200 Original-Received: from localhost ([127.0.0.1]:55908 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KAmR1-0003nC-F2 for ged-emacs-devel@m.gmane.org; Mon, 23 Jun 2008 09:50:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KAmQv-0003kb-83 for emacs-devel@gnu.org; Mon, 23 Jun 2008 09:50:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KAmQs-0003iB-GN for emacs-devel@gnu.org; Mon, 23 Jun 2008 09:50:11 -0400 Original-Received: from [199.232.76.173] (port=52820 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KAmQr-0003hz-WF for emacs-devel@gnu.org; Mon, 23 Jun 2008 09:50:10 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:1402 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 1KAmQq-00011s-Vp for emacs-devel@gnu.org; Mon, 23 Jun 2008 09:50:09 -0400 Original-Received: (qmail 46147 invoked by uid 3782); 23 Jun 2008 13:50:03 -0000 Original-Received: from acm.muc.de (pD9E52DCA.dip.t-dialin.net [217.229.45.202]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Mon, 23 Jun 2008 15:49:54 +0200 Original-Received: (qmail 7699 invoked by uid 1000); 23 Jun 2008 14:13:34 -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-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:99775 Archived-At: Hi, Miles! On Mon, Jun 23, 2008 at 05:37:39PM +0900, Miles Bader wrote: > In c-mode, I notice that C-M-a is bound to `c-beginning-of-defun', > overriding the global binding to `beginning-of-defun'. Yes. This is deliberate. > The generic `beginning-of-defun' function offers some additional > functionality (in particular, it sets the mark before jumping), and > seems to work just as well. `beginning-of-defun' sets the mark? This is something new, isn't it? It seems like a good idea, though. > We should generally try to avoid gratuitous mode-specific rebinding of > generic bindings that work properly. I don't agree that `beginning-of-defun', in particular `beginning-of-defun-function' works properly. > I suppose this rebinding made sense in the past when the generic > mechanism was less capable, but does it make sense any more? The problem is that c-beginning-of-defun is S L O W. It spends nearly all its time locating the pertinent top-level {, and then grappling its way to the start of the defun header from there, including the tortuous analysis of a possible (but usually absent) k&r parameter block of unbounded length. This latter is what caused such pain whilst doing C-x 4 a in C files several weeks ago. However, when given a repeat count, it only needs to do this tortuous analysis once., rapidly zapping back by sexps n-1 times. b-o-d is currently incapable of passing the repeat count to b-o-d-function, which means that the tortuous analysis would have to be repeated n times for an argument of n, were this mechanism to be used by CC Mode. I did some timings some while ago (on my now deceased 166 MHz box) on ..../src/keyboard.c. (c-beginning-of-defun 100) took 4 seconds. Looping (c-beginning-of-defun) 100 times took 44 seconds. > Any comments? I think beginning-of-defun-function should be passed the repeat count (naturally doing the right thing when that function can't take it). But we've had this discussion several times before on this list without reaching a consensus. > [A similar argument applies to other commands like c-end-of-defun] > Thanks, > -Miles -- Alan Mackenzie (Nuremberg, Germany).