From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Mysterious fontification/C++ context issue - Patch for beginning-of-defun-raw. Date: Fri, 15 Dec 2006 00:03:16 -0500 Message-ID: Reply-To: rms@gnu.org NNTP-Posting-Host: dough.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1166159033 1854 80.91.229.10 (15 Dec 2006 05:03:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 15 Dec 2006 05:03:53 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 15 06:03:53 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 1Gv5Ee-0007G5-5x for ged-emacs-devel@m.gmane.org; Fri, 15 Dec 2006 06:03:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gv5Ed-0007FY-OH for ged-emacs-devel@m.gmane.org; Fri, 15 Dec 2006 00:03:51 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gv5E6-00076E-G0 for emacs-devel@gnu.org; Fri, 15 Dec 2006 00:03:18 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gv5E5-00075n-ST for emacs-devel@gnu.org; Fri, 15 Dec 2006 00:03:17 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gv5E5-00075i-Hp for emacs-devel@gnu.org; Fri, 15 Dec 2006 00:03:17 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gv5E5-0007Rw-3g for emacs-devel@gnu.org; Fri, 15 Dec 2006 00:03:17 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.52) id 1Gv5E4-0000Ei-La; Fri, 15 Dec 2006 00:03:16 -0500 Original-To: emacs-devel@gnu.org In-reply-to: message from David Kastrup on Fri, 15 Dec 2006 01:53:40 +0100 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:63753 Archived-At: I have now read the messages about this which arrived in the past week or two, and checked the code again. Basically, we have three different things in Emacs that need to find, more or less, "the start of this defun". * beginning-of-defun-raw. * syntax.el * find_defun_start in syntax.c There are different features for customizing each of these three. This is a very confusing situation. The change I asked for, to make open-paren-in-column-0-is-defun-start affect beginning-of-defun-raw, causes a major slowness. 4 seconds for M-> is too painful. So now I think that change should be undone. But just undoing it won't make everything ok. The name open-paren-in-column-0-is-defun-start implies to me that this variable ought to affect beginning-of-defun-raw. After all, that command finds a defun start. So if we make that variable apply only to syntax.c, as it used to, perhaps we should rename it to open-paren-in-column-0-is-outer-level. However, that name suggests that syntax.el ought to obey it too. That makes me wonder whether find_defun_start should use syntax-begin-function. Does that work right? If so, we could eliminate open-paren-in-column-0-is-defun-start. Stefan suggested something similar: making back_comment use syntax-ppss. How hard is that to implement? Stefan also suggested we arrange another better way to customize beginning-of-defun (and the parts of Font Lock that highlight things that look like beginnings of defuns). With those two changes, open-paren-in-column-0-is-defun-start could be eliminated. As for fixing the misfontifications of C mode, David Kastrup wrote: The large slowdown most likely would not be necessary if information was reused intelligently and not scanned repeatedly. That requires a good analysis and careful implementation/reimplementation. I agree with him that that is worth trying, but only after the release. A different but related question: Should C mode do (setq beginning-of-defun-function 'c-beginning-of-defun) Is there any reason that would be bad?