From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: Mysterious fontification/C++ context issue Date: Sun, 10 Dec 2006 20:05:49 -0500 Message-ID: References: <87y7po2e9b.fsf@leeloo.anubex.internal> <45741FBE.3000107@swipnet.se> <45742464.1090504@gmx.at> <20061204203024.D17603@colin2.muc.de> <45768797.5010106@gmx.at> <87odqhj89q.fsf@stupidchicken.com> <20061210014526.GB3738@muc.de> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1165799260 5549 80.91.229.10 (11 Dec 2006 01:07:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 11 Dec 2006 01:07:40 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, Chong Yidong , Richard Stallman , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 11 02:07:39 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 1GtZdp-0000VV-9r for ged-emacs-devel@m.gmane.org; Mon, 11 Dec 2006 02:07:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GtZdo-00076O-Me for ged-emacs-devel@m.gmane.org; Sun, 10 Dec 2006 20:07:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GtZc9-00060u-0r for emacs-devel@gnu.org; Sun, 10 Dec 2006 20:05:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GtZc8-0005zP-2d for emacs-devel@gnu.org; Sun, 10 Dec 2006 20:05:52 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GtZc7-0005zE-Sm; Sun, 10 Dec 2006 20:05:51 -0500 Original-Received: from [209.226.175.184] (helo=tomts22-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GtZc6-0002c7-M6; Sun, 10 Dec 2006 20:05:50 -0500 Original-Received: from pastel.home ([70.55.82.240]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20061211010549.MVZD8030.tomts22-srv.bellnexxia.net@pastel.home>; Sun, 10 Dec 2006 20:05:49 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 51AD5812C; Sun, 10 Dec 2006 20:05:49 -0500 (EST) Original-To: Alan Mackenzie In-Reply-To: <20061210014526.GB3738@muc.de> (Alan Mackenzie's message of "10 Dec 2006 01\:35\:13 +0100\, Sun\, 10 Dec 2006 01\:45\:26 +0000") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux) 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:63558 gmane.emacs.pretest.bugs:15658 Archived-At: >> Could we set open-paren-in-column-0-is-defun-start to t for c mode? > This would nullify the fix for the bug reported by Martin a few weeks > ago, namely: Load syntax.c and immediately jump forward to a certain > function. The fontification was seriously wrong. These limitations have existed for years. In elisp (and in c-mode at some point during the development of Emacs-22), we addressed those problems not by fixing them but instead by highlighting in `warning' face the pieces of code that can cause such problems. Such limitations are not necessarily that bad. After all, if you write your code in a sufficiently odd way, the indentation engine will also get completely confused. Emacs only provides good support for code written in a sufficiently idiomatic way. > I think I now agree with Martin R: opic0ids should become a fully user > settable option, and CC Mode should respect it. I think I agree. But I'd do it slightly differently. The "open-paren-in-col0" is a heuristic that makes sense in some modes but not all. Other modes may want another heuristic. The heuristic itself is currently specified/enabled via `syntax-begin-function' whose value may use things like beginning-of-defun. I think the user's control should be on syntax-begin-function (e.g. by adding a Custom var that forces Emacs to ignore the syntax-begin-function setting). > I'm not 100% sure what effect this would have on CC Mode, but it'll be > something like this: c-beginning-of-defun will continue to look for an > unnested {, but with (eq opic0ids t), its results will be probabalistic > rather than rigorous. But it worked well enough before, when > beginning-of-defun was a bit squidgy. And if the user chooses to let the major mode use some heuristic, it'd be good for the major mode to flag (to the extent possible) those places where the heuristic is in error. In the same area: the change in beginning-of-defun which treats open-paren-in-column-0-is-defun-start specially when defun-prompt-regexp is nil (and which currently leads to oddball cases where point can end up in the middle of an parenthesized expression, as shown by Martin's examples) should be replaced by a new var "b-d-f-check-syntax" which if non-nil causes beginning-of-defun to skip the false matches (i.e. parens-in-col0 or defun-prompt-regexp matches that are not at toplevel) by checking syntax-ppss. Stefan