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 19:26:59 +0100 Message-ID: <20061214193733.GA1269@muc.de> References: <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> <45812BDF.5050107@gmx.at> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1166120842 16937 80.91.229.10 (14 Dec 2006 18:27:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 14 Dec 2006 18:27:22 +0000 (UTC) Cc: Chong Yidong , 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 19:27: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 1GuvIa-0001Np-Qu for ged-emacs-devel@m.gmane.org; Thu, 14 Dec 2006 19:27:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuvIa-0001H1-GF for ged-emacs-devel@m.gmane.org; Thu, 14 Dec 2006 13:27:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GuvIN-0001EM-5S for emacs-devel@gnu.org; Thu, 14 Dec 2006 13:27:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GuvIM-0001Ds-Jn for emacs-devel@gnu.org; Thu, 14 Dec 2006 13:27:02 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuvIM-0001Dp-Gt for emacs-devel@gnu.org; Thu, 14 Dec 2006 13:27:02 -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 1GuvIL-0000bC-RV for emacs-devel@gnu.org; Thu, 14 Dec 2006 13:27:02 -0500 Original-Received: (qmail 70904 invoked by uid 3782); 14 Dec 2006 18:26:59 -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 19:26:56 +0100 (CET) Original-Received: (qmail 2015 invoked by uid 1000); 14 Dec 2006 19:37:33 -0000 Original-Date: Thu, 14 Dec 2006 19:37:33 +0000 Original-To: martin rudalics Content-Disposition: inline In-Reply-To: <45812BDF.5050107@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:63732 Archived-At: Grüßle Göttle, Martin! On Thu, Dec 14, 2006 at 11:47:59AM +0100, martin rudalics wrote: > >>Before the changes beginning-to-defun-raw, doing M-> to move to the > >>end of xdisp.c is instantaneous. [ .... ] > > 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. You're probably right, there. > > 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. We're down to philosophy/politics, here. Lots of CC Mode users, probably most, are not working on GNU projects - Linux hackers, for example, to say nothing of thousands (?hundreds of thousands) of programmers working in their day jobs. We shouldn't be ramming GNU standards down their throats - they should have the freedom to accept or ignore these. In normal, carefree use, an open paren/brace in column 0 doesn't happen that often. A typical user won't notice when a M-q in a string puts a ( at column 0, so when the fontification goes awry, it's a big jolt, and an indefinite time sink to sort out (or ignore) the problem. 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". Comments, please! > 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 They do that already. Most of them neither know nor care about the GNU rule. I don't know of any program (aside from Obfuscated C entries) where programmers knowingly put { or ( in C0 (apart from defun openers). It's something that just happens, much as it did in syntax.c. Now that we've got 1 to 4 GHz processors, (eq opic0ids nil) is a reasonable default for C. If we can just agree on a mechanism, I will amend cc-mode.el to avoid forcing the sluggishness down people's throats. I actually feel quite guilty about that, believe it or not. > - implicitly forcing the authors of other tools to abandon the rule as > well. They will be experiencing the same hiccups as Emacs. By the way, what other tools? ;-) > If that's the intention, GNU should change the coding standard first. I think that's a separate issue. Maybe these other tools could now be adapted to recognise parens inside strings and comments, now that processors are fast. Maybe not. -- Alan.