From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: Mysterious fontification/C++ context issue Date: 6 Dec 2006 21:52:55 +0100 Message-ID: <20061206220256.GB1347@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> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1165438403 27333 80.91.229.10 (6 Dec 2006 20:53:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Dec 2006 20:53:23 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-pretest-bug@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 06 21:53:21 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 1Gs3lS-0005VB-7R for ged-emacs-devel@m.gmane.org; Wed, 06 Dec 2006 21:53:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gs3lR-0005uF-R1 for ged-emacs-devel@m.gmane.org; Wed, 06 Dec 2006 15:53:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gs3lH-0005u5-Ef for emacs-devel@gnu.org; Wed, 06 Dec 2006 15:53:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gs3lD-0005td-Md for emacs-devel@gnu.org; Wed, 06 Dec 2006 15:53:03 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gs3lD-0005ta-IW for emacs-devel@gnu.org; Wed, 06 Dec 2006 15:52:59 -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 1Gs3lD-0004zZ-CU for emacs-devel@gnu.org; Wed, 06 Dec 2006 15:52:59 -0500 Original-Received: (qmail 7314 invoked by uid 3782); 6 Dec 2006 20:52:55 -0000 Original-Received: from acm.muc.de (p54A3F359.dip.t-dialin.net [84.163.243.89]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Wed, 06 Dec 2006 21:52:53 +0100 (CET) Original-Received: (qmail 3353 invoked by uid 1000); 6 Dec 2006 22:02:56 -0000 Original-Date: Wed, 6 Dec 2006 22:02:56 +0000 Original-To: martin rudalics Content-Disposition: inline In-Reply-To: <45768797.5010106@gmx.at> 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:63380 gmane.emacs.pretest.bugs:15515 Archived-At: Evening, Martin! On Wed, Dec 06, 2006 at 10:04:23AM +0100, martin rudalics wrote: [ .... ] > Thanks for taking care of this. Please note: > 1. You don't widen the buffer before calling `syntax-ppss'. You mean I don't have to, and would get the same result without widening? I need to widen anyway, in case point is inside a comment/string and (point-min) is after the c/s's start. > 2. A construct built along > (foo > ) (bar) > with point at "bar" might derail font-lock (remember, > `c-beginning-of-defun-1' calls `beginning-of-defun', not > `beginning-of-defun-raw'). I think it's best to keep the discussion of beginning-of-defun and the CC Mode stuff separate. Once b-o-d works right, the question is then how CC Mode should use it. You discuss this below. > 3. All this is still awfully slow and expensive: Open a larger buffer > like xdisp.c, jump to its end, hit M-v a couple of times, and look at > CPU consumption. UURRRKkk!! That's not good! It took me ~6 seconds, and that's not even on my (deceased) 166 MHz box. That file is the best part of a megabyte, though. > 4. You could avoid the tedious `up-list' steps by using a variant of the > tentative fix I attached. (nth 9 ppss) is "Internal data for continuing the parsing". If we're going to be using that thing's car as "the least nested paren", why don't we give up the pretence of an "internal" variable and document it properly? I know it's used in some other places too, but it seems to be being economical with our integrity to use it ourselves whilst telling everybody else "it's internal stuff". Or has this been discussed already? Your patch is more compact than mine was, and makes scrolling in xdisp.c acceptably (to me) fast. In fact, that 6 seconds has been reduced to about half a second. So it gets my vote. (I've got a 1.2 GHz Athlon machine, by the way.) Just a small point, though: your patch doesn't handle the silly case (beginning-of-defun 0). I think this should mean "point doesn't move". Is it the `up-list' calls which slow my version down so much? > 5. Consider making `open-paren-in-column-0-is-defun-start' a real user > option in C mode. Let, for example, users decide whether they want to > respect GNU coding standards [ .... ]. I think I might agree with this, now. Or is your version of beginning-of-defun-raw fast enough so that this doesn't really matter? I think there are lots of programmers who hang braces which open defuns. I think Java hackers do it a lot. But we need to implement this in a way which doesn't repeat the unholy hassle we had with `require-final-newline'. I don't think there should be a variable `c-open-paren....-start" - the name's long enough already. ;-) Maybe CC Mode should make o-p-i-c-o-i-d-s local in each of its buffers. > This should also permit binding C-M-a / C-M-e to `c-beginning-of-defun' > / `c-end-of-defun' when `open-paren-in-column-0-is-defun-start' is nil. Indeed. > 6. In any case, the new behavior should be documented since it applies > whenever `open-paren-in-column-0-is-defun-start' is set to nil. What new behaviour? But Richard asked that. -- Alan Mackenzie (Ittersbach, Germany)