From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Mysterious fontification/C++ context issue - Patch for beginning-of-defun-raw. Date: Thu, 14 Dec 2006 11:47:59 +0100 Message-ID: <45812BDF.5050107@gmx.at> References: <45768797.5010106@gmx.at> <87odqhj89q.fsf@stupidchicken.com> <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> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1166093478 13146 80.91.229.10 (14 Dec 2006 10:51:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 14 Dec 2006 10:51:18 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org, Richard Stallman , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 14 11:51:15 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 1GuoBB-0000c8-JD for ged-emacs-devel@m.gmane.org; Thu, 14 Dec 2006 11:51:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuoBB-0006d5-1c for ged-emacs-devel@m.gmane.org; Thu, 14 Dec 2006 05:51:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GuoAy-0006bj-KR for emacs-devel@gnu.org; Thu, 14 Dec 2006 05:50:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GuoAx-0006b3-Jk for emacs-devel@gnu.org; Thu, 14 Dec 2006 05:50:56 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuoAx-0006ax-FA for emacs-devel@gnu.org; Thu, 14 Dec 2006 05:50:55 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1GuoAx-0003j5-AM for emacs-devel@gnu.org; Thu, 14 Dec 2006 05:50:55 -0500 Original-Received: (qmail invoked by alias); 14 Dec 2006 10:50:54 -0000 Original-Received: from N828P022.adsl.highway.telekom.at (EHLO [62.47.47.118]) [62.47.47.118] by mail.gmx.net (mp034) with SMTP; 14 Dec 2006 11:50:54 +0100 X-Authenticated: #14592706 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en Original-To: Alan Mackenzie In-Reply-To: <20061214084713.GA1333@muc.de> X-Y-GMX-Trusted: 0 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:63712 Archived-At: >>Before the changes beginning-to-defun-raw, doing M-> to move to the >>end of xdisp.c is instantaneous. > > > Hey, that's not fair! When you raised this problem, you were > complaining about how slow a M-v was, after having got to EOF. Is this > M-v now acceptably fast for you on your 1.7 GHz machine? > > >>With the patch applied, M-> takes four seconds. This is on a Pentium 4 >>1700MHz computer. > > > It's worth pointing out that this is only the first time. If you then > do M-< and another M->, these are then instantaneous. If (some) cache > later gets disrupted, then the M-> would be a bit slow again. > > Do you have any idea why M->, which is surely nothing more than > (goto-char (point-max)) is so slow? I have an idea it is the filling of > CC Mode's cache. M-> ran almost instantaneously before `beginning-of-defun-raw' changed. And you did fill CC Mode's cache already before the change. I could imagine it's because font-locking runs `beginning-of-defun' repeatedly for decreasing buffer positions and the `syntax-ppss' cache doesn't handle these cases optimally. > It isn't only Emacs source files. It happens a lot in normal users' > files.c. There's a FAQ about it in the CC Mode manual. After all, > having parentheses inside strings and comments in C is perfectly valid > and acceptable syntax, and it looks like a bug (which indeed it is), if > Emacs can't fontify such things properly. That statement is not fair either: Nobody doubted the validity of parentheses inside strings and comments. The problem is due to non-escaped parens in the leftmost column that do not start a defun. Such parens do not follow GNU coding standards (Section 5.5.1, as of November 15, 2006): It is important to put the open-brace that starts the body of a C function in column one, and avoid putting any other open-brace or open-parenthesis or open-bracket in column one. Several tools look for open-braces in column one to find the beginnings of C functions. These tools will not work on code not formatted that way. If C mode were to weaken that rule we'd end up in a situation where - more and more programmers put parens that do not start defuns in the leftmost column (after all the GNU editor doesn't complain and they already pay with their CPU time for that extra service), thus - implicitly forcing the authors of other tools to abandon the rule as well. If that's the intention, GNU should change the coding standard first.