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: 14 Dec 2006 23:18:22 +0100 Message-ID: <20061214232857.GA1239@muc.de> References: <20061210014526.GB3738@muc.de> <877ix0lfm8.fsf@furball.mit.edu> <20061210102249.GA1235@muc.de> <87d56rpk7a.fsf@stupidchicken.com> <20061213224009.GA1206@muc.de> <87odq72ssy.fsf@stupidchicken.com> <20061214084713.GA1333@muc.de> <45812BDF.5050107@gmx.at> <20061214193733.GA1269@muc.de> <877iwuxljy.fsf@stupidchicken.com> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1166134724 7015 80.91.229.10 (14 Dec 2006 22:18:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 14 Dec 2006 22:18:44 +0000 (UTC) Cc: martin rudalics , Richard Stallman , Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 14 23:18:43 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 1GuyuY-00011S-Ol for ged-emacs-devel@m.gmane.org; Thu, 14 Dec 2006 23:18:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuyuY-00052N-5H for ged-emacs-devel@m.gmane.org; Thu, 14 Dec 2006 17:18:42 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GuyuJ-000502-Ut for emacs-devel@gnu.org; Thu, 14 Dec 2006 17:18:27 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GuyuJ-0004zK-6m for emacs-devel@gnu.org; Thu, 14 Dec 2006 17:18:27 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuyuJ-0004z9-1i for emacs-devel@gnu.org; Thu, 14 Dec 2006 17:18:27 -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 1GuyuI-00026B-Mw for emacs-devel@gnu.org; Thu, 14 Dec 2006 17:18:27 -0500 Original-Received: (qmail 54825 invoked by uid 3782); 14 Dec 2006 22:18:22 -0000 Original-Received: from acm.muc.de (p54A3E86F.dip.t-dialin.net [84.163.232.111]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Thu, 14 Dec 2006 23:18:20 +0100 (CET) Original-Received: (qmail 1830 invoked by uid 1000); 14 Dec 2006 23:28:57 -0000 Original-Date: Thu, 14 Dec 2006 23:28:57 +0000 Original-To: Chong Yidong Content-Disposition: inline In-Reply-To: <877iwuxljy.fsf@stupidchicken.com> 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:63746 Archived-At: Hi, Chong! On Thu, Dec 14, 2006 at 03:35:45PM -0500, Chong Yidong wrote: > Alan Mackenzie writes: > > I say we should GIVE THE USER THE CHOICE. I have proposed a way of > > doing this to which nobody's commented yet: Have three values for > > the variable with the furlong long name, namely (t nil mode). t and > > nil will carry on meaning what they mean, and the symbol 'mode, the > > default, will mean "Major mode may set its own default here". > We should also introduce a new variable, call it > c-open-paren-in-column-0-is-defun-start, defaulting to t. This approach was tried with c-require-final-newline. It lead to a lot of confusion (with require-final-newline) and even resentment. A consensus was reached that c-require-final-newline was a bad solution to a problem. What problems do you see with open-paren-in-column-0-is-defun-start having the default 'mode? > Furthermore, C-mode should define its own beginning-of-defun-function, > and the syntax-pps code that was inserted into beginning-of-defun-raw > should be relocated to that function. Furthermore, the syntax-pps > code should not be the default behavior, taking effect only if > c-o-p-i-c-0-i-d-s is nil. CC Mode has its own b-o-d-f, c-beginning-of-defun. However, it relies on a beginning-of-defun before it has filled its own structure cache. The ppss version of b-o-d expresses the original intent of that function, namely to find an outermost open-paren. The Emacs core is surely the right place for this, since it is a generally useful functionality. > (As I and other people have pointed out, defaulting to nil leads to > unacceptable slowness for moderately big C files on even fast > machines. People can set it to t if they are running on 1000000 Ghz > machines and want to put there parens where they please.) Well, xdisp.c is a massive file, not a moderately big one, and I wouldn't find the slowness unacceptable, though that's obviously a personal thing. If it were 15 seconds rather than 4, I would freak out like you're doing now. I would find massive misfontification (as happened in syntax.c, the bug for which the pertinent patch is a repair) totally unacceptable. This is why I have suggested making the thing configurable. Another possibility would be a variable like this in place of opic0ids: (defvar threshold-ppss-bod 200000 "The buffer size above which a paren in column0 will signal a defun start. Below this size, a paren at the top level signals a defun start. If this variable is nil, a paren at top level is always used. If t, a paren in column 0 is always used.") What do you think? With the patch I suggested last night, you still find an initial M-> in xdisp.c too slow (~4 seconds on your 1.7 GHz PC). That's a massively large file. How fast must this operation be before you'd find it acceptable? In emacs/src, there are files.c of all sizes, ranging from pre-crt0.c (484 bytes) to xdisp.c (722032 bytes). If David Kastrup's conjectured "quadratic dependency" were true (I don't think it is), then a "typical" sized file.c (say, eval.c at just over 100k) would take ~0.1 seconds for this. If the dependency is linear, it would take ~0.5 seconds. Please satisfy my curiosity, experiment with decreasing file sizes, and tell me at what file size the reaction becomes too slow for you. -- Alan.