From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: AW: font-locking and open parens in column 0 Date: Fri, 10 Nov 2006 23:52:50 -0500 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1163220807 9365 80.91.229.2 (11 Nov 2006 04:53:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 11 Nov 2006 04:53:27 +0000 (UTC) Cc: AMackenzie@harmanbecker.com, emacs-devel@gnu.org, rudalics@gmx.at Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 11 05:53:22 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 1Gikrk-0004aC-QZ for ged-emacs-devel@m.gmane.org; Sat, 11 Nov 2006 05:53:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gikrk-0008O8-76 for ged-emacs-devel@m.gmane.org; Fri, 10 Nov 2006 23:53:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GikrY-0008M9-8s for emacs-devel@gnu.org; Fri, 10 Nov 2006 23:53:04 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GikrW-0008Lr-LW for emacs-devel@gnu.org; Fri, 10 Nov 2006 23:53:04 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GikrW-0008Lm-Ft for emacs-devel@gnu.org; Fri, 10 Nov 2006 23:53:02 -0500 Original-Received: from [209.226.175.110] (helo=tomts43-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GikrT-00080M-0Z; Fri, 10 Nov 2006 23:52:59 -0500 Original-Received: from pastel.home ([74.12.205.93]) by tomts43-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20061111045254.DNOV1596.tomts43-srv.bellnexxia.net@pastel.home>; Fri, 10 Nov 2006 23:52:54 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id DA3967F88; Fri, 10 Nov 2006 23:52:50 -0500 (EST) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Fri\, 10 Nov 2006 21\:11\:20 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.90 (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:62061 Archived-At: >> The purpose of open-paren-in-column-0-is-defun-start is to enable to >> disable this heuristic. Setting it to nil disables the heuristic. >> So I think his change is correct. > Huh? What do you mean by "heuristic". > Emacs is looking for an open-paren at top level in list structure. When? We're talking about a patch to beginning-of-defun, right? Beginning-of-defun has until now been defined by regexps. > The heuristic is to take an open-paren at column zero and assume > it is at top level. The docstring of beginning-of-defun doesn't say anything about "toplevel". AFAIK beginning-of-defun is a function in the same category as forward-paragraph and things like that, which do not care much about the global syntax state, but instead only pay attention to the immediately surrounding text. > I am having trouble relating the rest of your message to this issue. > This is just a matter of implementing > open-paren-in-column-0-is-defun-start = nil to do what it says it will do. The discussion about beginning-of-defun is intricately tied to syntax-ppss because: 1 - it started with a bug-report about wrong font-locking because beginning-of-defun is apparently used by cc-mode to get a safe starting point for syntactic analysis. 2 - beginning-of-defun has been used as a syntax-begin-function in several occasions, as a heuristic to find a safe starting point for syntactic analysis. 3 - changing beginning-of-defun to use parse-partial-sexp (or worse syntax-ppss) defeats the purpose of using it as a syntax-begin-function. It may even break such uses (e.g. in emacs-lisp-mode). 4 - the original motivation for the patch (i.e. point 1 above) is better addressed by not using beginning-of-defun and rely on syntax-ppss's cache instead. I think the problem is that beginning-of-defun has many different possible uses, not all of which are compatible: 1 - it can be used as a "move to toplevel" (i.e. outside of any syntactic element). Currently it's a not reliable way to do that, but it's been used as a good heuristic. Note that in some languages such a concept may not even be very meaningful: in languages whose files are commonly composed of only one toplevel element (typically a module or a class which then contains other elements inside themselves maybe classes or modules, ...). 2 - it can be used as a form of "backward-paragraph-for-prog-langs", to move to the beginning of a "block of text". In case where defuns can be nested, this first only move to the beginning of the nested defun. 3 - a mix of the two: define some level of nesting (if any) as the main one (typically either the toplevel one, or if the toplevel is a single element, use the next level down) and move to the beginning of the defun at that level. Interactive use mostly wants behavior 2 or 3. A reliable way to get behavior 1 is to use syntax-ppss rather than beginning-of-defun. The proposed patch basically tries to make beginning-of-defun follow the behavior number 1 and to make it do so reliably. Given the availability of syntax-ppss to get the same result, I don't think this patch is such a good idea. OTOH it might be a good idea indeed to change beginning-of-defun so that it ignores regexp-matches if they're inside comments or strings. But that'd be a different patch, which would apply regardless of open-paren-in-column-0-is-defun-start. Stefan