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: Mysterious fontification/C++ context issue Date: 10 Dec 2006 11:56:21 +0100 Message-ID: <20061210120636.GB1235@muc.de> References: <87y7po2e9b.fsf@leeloo.anubex.internal> <45741FBE.3000107@swipnet.se> <45742464.1090504@gmx.at> <20061204203024.D17603@colin2.muc.de> <45768797.5010106@gmx.at> <4577465E.9060606@gmx.at> <457A84F3.5030205@gmx.at> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1165748208 17134 80.91.229.10 (10 Dec 2006 10:56:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 10 Dec 2006 10:56:48 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 10 11:56:45 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by dough.gmane.org with esmtp (Exim 4.50) id 1GtMMJ-000377-SV for ged-emacs-devel@m.gmane.org; Sun, 10 Dec 2006 11:56:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GtMMJ-0005MC-CW for ged-emacs-devel@m.gmane.org; Sun, 10 Dec 2006 05:56:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GtMM6-0005LP-1o for emacs-devel@gnu.org; Sun, 10 Dec 2006 05:56:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GtMM4-0005KN-2x for emacs-devel@gnu.org; Sun, 10 Dec 2006 05:56:25 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GtMM3-0005KE-UH for emacs-devel@gnu.org; Sun, 10 Dec 2006 05:56:23 -0500 Original-Received: from [193.149.48.1] (helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GtMM3-0004hB-IW for emacs-devel@gnu.org; Sun, 10 Dec 2006 05:56:24 -0500 Original-Received: (qmail 78043 invoked by uid 3782); 10 Dec 2006 10:56:21 -0000 Original-Received: from acm.muc.de (p54A3DF4F.dip.t-dialin.net [84.163.223.79]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Sun, 10 Dec 2006 11:56:19 +0100 (CET) Original-Received: (qmail 3057 invoked by uid 1000); 10 Dec 2006 12:06:36 -0000 Original-Date: Sun, 10 Dec 2006 12:06:36 +0000 Original-To: Richard Stallman , martin rudalics Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) X-Primary-Address: acm@muc.de 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:63541 Archived-At: Hi, Richard, hi, Martin! On Sat, Dec 09, 2006 at 11:24:54PM -0500, Richard Stallman wrote: > > 2. That a user's idea of "defun" for her programming > > language does not necessarily coincide with that of > > `beginning-of-defun'. > > > > The major mode is supposed to try to make them correspond. It > > seems strange to assume that it doesn't succeed. beginning-of-defun unfortunately conflates (i) "beginning of a function" and (ii) "outermost level of parens", this arising because they coincide in the most important language (Lisp). Having "beginning-of-defun-function" makes things even worse. Typically, b-o-d (sense (i)) is going to be calling foo-beginning-of-defun (the value of b-o-d-function) which is going to be recursively calling beginning-of-defun (sense (ii)), getting one's knickers horribly twisted. Maybe, for Emacs 23, we could disentangle these things. > If it really succeeded why should C mode ever bother to provide > its own `c-beginning-of-defun'? c-beginning-of-defun puts point at the beginning of the C function, i.e. at the "int" in the following, regardless of whether the brace is hung or at column 0: int foo (bar) { .... } > Maybe C mode should arrange to use `c-beginning-of-defun' > as the beginning-of-definition-function. Is there a reason why > this would give bad results? Yes. You mean syntax-begin-function? c-beginning-of-defun is a user level function, and it's slow. About 90% of its runtime is spent determining where point is initially (inside a defun / inside "int foo (bar)" / at "int foo (bar)"/ ... ) and finally moving from the open brace to the "int". Only ~10% is used in finding the outermost open brace, which is all that's needed for font-locking and so on. > > Anyway, this is not the right place to discuss what happens in > > specific modes. > The current change affects the behavior of `beginning-of-defun' which > may affect other modes as well. > Yes, if they set `open-paren-in-column-0-is-defun-start' to t. You mean setting it to nil. ;-) The behaviour of beginning-of-defun has been changed ONLY for when opic0ids gets set to nil. The only other file.el within Emacs which does this is progmodes/python.el. Any Python users here? Dave Love, are you listening? There is also this baffling comment in net/tramp.el: ;; Fontification is messed up when ;; `open-paren-in-column-0-is-defun-start' set to t. -- Alan Mackenzie (Ittersbach, Germany)