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: AW: font-locking and open parens in column 0 Date: Fri, 03 Nov 2006 15:02:33 +0100 Message-ID: <454B4BF9.5090608@gmx.at> References: NNTP-Posting-Host: main.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 1162562717 11608 80.91.229.2 (3 Nov 2006 14:05:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 3 Nov 2006 14:05:17 +0000 (UTC) Cc: Alan Mackenzie , Richard Stallman , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 03 15:05:13 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GfzeA-0003uC-Jv for ged-emacs-devel@m.gmane.org; Fri, 03 Nov 2006 15:03:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GfzeA-0002ke-4V for ged-emacs-devel@m.gmane.org; Fri, 03 Nov 2006 09:03:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gfzda-00029A-RA for emacs-devel@gnu.org; Fri, 03 Nov 2006 09:03:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GfzdW-0001zW-Ai for emacs-devel@gnu.org; Fri, 03 Nov 2006 09:03:14 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GfzdV-0001zC-Tq for emacs-devel@gnu.org; Fri, 03 Nov 2006 09:03:09 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1GfzdV-0002my-EO for emacs-devel@gnu.org; Fri, 03 Nov 2006 09:03:09 -0500 Original-Received: (qmail invoked by alias); 03 Nov 2006 14:03:07 -0000 Original-Received: from N810P015.adsl.highway.telekom.at (EHLO [62.47.45.47]) [62.47.45.47] by mail.gmx.net (mp044) with SMTP; 03 Nov 2006 15:03:07 +0100 X-Authenticated: #14592706 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en Original-To: "Mackenzie, Alan" In-Reply-To: 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:61698 Archived-At: Good afternoon, Alan > 1 2 3 4 5 6 7 3 > I agree with you. :-) However, my patch is to do with > beginning-of-defun-raw, not font-locking. My problem is with font-locking and I thought your patch wanted to address that problem (as you also stated some lines below). > Are you saying that > open-paren-in-column-0-is-defun-start shouldn't exist at all? When it is > nil, a paren in column 0 may not, of itself, be regarded as a defun > start. I fail to understand the present state of things. On the one hand, `open-paren-in-column-0-is-defun-start' is customizable which means a user should be able to set it and a major mode should respect that. On the other hand, c-mode deliberately sets this to nil. I think users should be free to express their choice here if they consider their machine inapt for scanning from bob. > I would say, rather, that font-locking should not use b-o-defun-raw when > o-p-i-c-0-i-d-s is nil, except in exceptional circumstances. Font-lock uses `syntax-ppss' which may call `syntax-begin-function' which may be defined as `beginning-of-defun' which usually calls `beginning-of-defun-raw'. When I open a C file and jump to a position before stealth fontification gets there, that's the way things behave. > The case > you spotted in syntax.c (and I've really no idea how you did ;-), is > such an exceptional case. I spotted that incidentally when scrolling backwards through syntax.c. Anyway, it *is* exceptional and thus should not warrant any major change. Richard's patch just comes in handy. > CC Mode caches parenthesis structures. ... which parallels the work of `syntax-ppss', hence we currently end up with two caches for the same structures - I know c-mode has to work hard to handle all sorts of older (X)Emacsen ... > My patch did fix the bug (a whole screenful of misfontified string in > syntax.c), though, didn't it? It does fix it, and it's even pretty fast ;-). But I still think the "bug" is with the author who put the left paren in column zero of that comment. That author should be warned just as in emacs-lisp-mode. > You're talking about my patch to beginning-of-defun-raw, here, not the > stuff in CC Mode. I don't have the source files to hand at the moment. > > >>(1) Consult `syntax-ppss' first. >> >>(2) Try to use the 9th field of the return value of >>`parse-partial-sexp' >>to find the outermost paren instead of up-/forward-/backward-listing. >> >>(3) Crowd the cache of `syntax-ppss' in order to avoid further scans. > > > OK, thanks! I'll need to learn about these optimisations. > begining-of-defun-raw, when used in font locking, could be distressingly > slow without them. Suggestion (1) obviously has nothing to do with font-locking (otherwise we would end up with `syntax-ppss' calling `beginning-of-defun' calling `syntax-ppss' ...) but with using `beginning-of-defun' interactively for jumping to the beginning of the current function. However, that's something `c-beginning-of-defun' does perfectly for c-mode.