From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.pretest.bugs,gmane.emacs.devel Subject: Re: Mysterious fontification/C++ context issue Date: Wed, 06 Dec 2006 23:38:58 +0100 Message-ID: <45774682.7070204@gmx.at> References: <87y7po2e9b.fsf@leeloo.anubex.internal> <45741FBE.3000107@swipnet.se> <45742464.1090504@gmx.at> <20061204203024.D17603@colin2.muc.de> <45768797.5010106@gmx.at> <20061206220256.GB1347@muc.de> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1165444958 22683 80.91.229.10 (6 Dec 2006 22:42:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Dec 2006 22:42:38 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-pretest-bug@gnu.org, emacs-devel@gnu.org Original-X-From: cc-mode-help-bounces@lists.sourceforge.net Wed Dec 06 23:42:36 2006 Return-path: Envelope-to: sf-cc-mode-help@m.gmane.org Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by dough.gmane.org with esmtp (Exim 4.50) id 1Gs5TE-0005Hj-Ug for sf-cc-mode-help@m.gmane.org; Wed, 06 Dec 2006 23:42:33 +0100 Original-Received: from sc8-sf-list1-new.sourceforge.net (sc8-sf-list1-new-b.sourceforge.net [10.3.1.93]) by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP id 4BC3B122B9; Wed, 6 Dec 2006 14:42:32 -0800 (PST) Original-Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1Gs5TB-00074M-KN for cc-mode-help@lists.sourceforge.net; Wed, 06 Dec 2006 14:42:29 -0800 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1Gs5T6-0005u7-Ge for cc-mode-help@lists.sourceforge.net; Wed, 06 Dec 2006 14:42:26 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.52) id 1Gs5T0-0005Ha-20 for bug-cc-mode@gnu.org; Wed, 06 Dec 2006 17:42:18 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1Gs5Sy-0008LW-Nd for bug-cc-mode@gnu.org; Wed, 06 Dec 2006 17:42:18 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1Gs5Sy-0008LE-2D for bug-cc-mode@gnu.org; Wed, 06 Dec 2006 17:42:16 -0500 Original-Received: (qmail invoked by alias); 06 Dec 2006 22:42:14 -0000 Original-Received: from N906P029.adsl.highway.telekom.at (EHLO [62.47.57.61]) [62.47.57.61] by mail.gmx.net (mp001) with SMTP; 06 Dec 2006 23:42:14 +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: <20061206220256.GB1347@muc.de> X-Y-GMX-Trusted: 0 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on monty-python X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4 X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: "Bug reports, feature requests, and general talk about CC Mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: cc-mode-help-bounces@lists.sourceforge.net Errors-To: cc-mode-help-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.cc-mode.general:4176 gmane.emacs.pretest.bugs:15517 gmane.emacs.devel:63383 Archived-At: > Evening, Martin! Evening, Alan! >>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. No, I mean you have to widen _before_ calling `syntax-ppss'. > > >>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. In my example `beginning-of-defun' would move to the beginning of the line and thus not to the outermost level. >>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? I don't know. But it is used in `syntax-ppss' and since you already call that we probably shouldn't care. Just add the same comment as `syntax-ppss' does and let things evolve. > 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.) You win, mine is a 1 GHz Athlon. > 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". That's what I meant by "tentative" ;-) you'll find more of that. > Is it the `up-list' calls which slow my version down so much? Depends on your mileage, parsing backward is not entirely trivial, you always have to check for stray comments. >>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 don't think so. > 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. In any case, it should be the user's responsibility - and I'm a user here myself ... ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV