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 - Patch for beginning-of-defun-raw. Date: 17 Dec 2006 12:10:41 +0100 Message-ID: <20061217122130.GA2643@muc.de> References: <4583C7D3.1070703@gmx.at> <45843AA5.5080906@gmx.at> <45844243.4060706@gmx.at> <87hcvvzlco.fsf@stupidchicken.com> <4584500B.7020303@gmx.at> <87d56jzjn3.fsf@stupidchicken.com> <8764cbzg5e.fsf@stupidchicken.com> <458483D2.9020809@gmx.at> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1166353962 5223 80.91.229.10 (17 Dec 2006 11:12:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 17 Dec 2006 11:12:42 +0000 (UTC) Cc: martin rudalics , Chong Yidong , Richard Stallman , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 17 12:12:41 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 1Gvtwa-0008Vp-6I for ged-emacs-devel@m.gmane.org; Sun, 17 Dec 2006 12:12:36 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GvtwZ-0001Im-53 for ged-emacs-devel@m.gmane.org; Sun, 17 Dec 2006 06:12:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gvtur-0000qz-H4 for emacs-devel@gnu.org; Sun, 17 Dec 2006 06:10:50 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gvtup-0000p8-D3 for emacs-devel@gnu.org; Sun, 17 Dec 2006 06:10:48 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gvtuo-0000oh-OO for emacs-devel@gnu.org; Sun, 17 Dec 2006 06:10:47 -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 1Gvtuo-0005Bc-4M for emacs-devel@gnu.org; Sun, 17 Dec 2006 06:10:46 -0500 Original-Received: (qmail 28713 invoked by uid 3782); 17 Dec 2006 11:10:41 -0000 Original-Received: from acm.muc.de (p54A3EEA3.dip.t-dialin.net [84.163.238.163]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Sun, 17 Dec 2006 12:10:39 +0100 (CET) Original-Received: (qmail 3893 invoked by uid 1000); 17 Dec 2006 12:21:31 -0000 Original-Date: Sun, 17 Dec 2006 12:21:30 +0000 Original-To: Stefan Monnier 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:63883 Archived-At: Morning, Stefan! On Sat, Dec 16, 2006 at 07:04:19PM -0500, Stefan Monnier wrote: > >> I still haven't seen any explanation for why this code needs to be > >> in beginning-of-defun-raw. This isn't true, for any normal value of "needs". I think it's more accurate to say that you don't accept that the explanation that has been given is a strong enough justification for the extra code in b-d-d-raw, which is fair enough. > > Well, it doesn't harm either. > Huh? Have you looked at the beginning-of-defun-raw code before the > change and compared to the monster it has become? All this > (apparently) because cc-mode wants to use syntax-ppss-toplevel-pos via > this function rather than calling it directly? No, it's deeper than that. It's to make the function match its documentation (see "Left Margin Paren" in the Emacs manual). It's to make things work consistently when opic0ids is nil. Everybody in this discussion whose native language is English agrees on this point. ;-) To be explicit, here is the argument, which has already appeared in this thread: (i) The meaning of "beginning-of-defun" in a source file is, and always has been, a paren at top level. This proved too slow in early versions of Emacs, and so the "column 0" heuristic was adopted. This has been documented in the Emacs manual since time immemorial; see page "Left Margin Paren" in the Emacs 21 manual (i.e. before I made any changes to it. ;-) (iii) This column 0 heuristic is just that - a heuristic, not a definition of b-o-d. (iv) The variable open-paren-in-column-0-is-defun-start was introduced in the murky past, and there doesn't seem to be a record of why. I can't find any discussion of it in the emacs-devel archives. However, it's doc-string states: "Non-nil means an open paren in column 0 denotes the start of a defun". Otherwise put, "non-nil means that the column 0 heuristic applies". (v) By pure logic, this MUST extend to "nil means the column 0 heuristic does NOT apply". Otherwise the variable would be meaningless. (vi) When opic0ids is nil, b-o-d-raw must seek the beginning-of-defun using the actual definition of b-o-d, namely a paren at top level. That is the argument. If you don't accept it, say so, and argue against it. But please stop saying that there is no argument. > I want to remove that code and go back to what it was before, unless I > can find a *good* explanation for why it needs to be in > beginning-of-defun-raw. Without that code, when opic0ids is nil, beginning-of-defun doesn't do the right thing: it finds a column 0 parenthesis rather than one at top level. That has been the state up till now, and is _very_ confusing for Elisp hackers. That said, you and Martin R. have convinced me that setting opic0ids to nil is the Wrong Thing to do in CC Mode. Not only is it too sluggish for big files, but bad parentheses early in a file.c would foul up the fontification (and maybe even the syntactic analysis) of all defuns after it. I think we should strive to eliminate all this b-o-d confusion after Emacs 22 has been released. > Stefan -- Alan.