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: AW: font-locking and open parens in column 0 Date: Sun, 12 Nov 2006 00:14:52 -0500 Message-ID: References: Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1163308670 25308 80.91.229.2 (12 Nov 2006 05:17:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 12 Nov 2006 05:17:50 +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 Sun Nov 12 06:17:48 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 1Gj7j2-0003ZA-Dj for ged-emacs-devel@m.gmane.org; Sun, 12 Nov 2006 06:17:48 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gj7j1-0003F3-Sy for ged-emacs-devel@m.gmane.org; Sun, 12 Nov 2006 00:17:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gj7gE-0001lM-A8 for emacs-devel@gnu.org; Sun, 12 Nov 2006 00:14:54 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gj7gD-0001kv-Go for emacs-devel@gnu.org; Sun, 12 Nov 2006 00:14:53 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gj7gD-0001kp-DJ for emacs-devel@gnu.org; Sun, 12 Nov 2006 00:14:53 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gj7gD-0006a2-CQ for emacs-devel@gnu.org; Sun, 12 Nov 2006 00:14:53 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1Gj7gC-0000mI-PG; Sun, 12 Nov 2006 00:14:52 -0500 Original-To: Stefan Monnier In-reply-to: (message from Stefan Monnier on Fri, 10 Nov 2006 23:52:50 -0500) 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:62100 Archived-At: 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. The specific purpose of the change in beginning-of-defun-raw was simply to make it correctly handle the case of open-paren-in-column-0-is-defun-start = nil when there is no beginning-of-defun-function. I know this discussion is part of a larger one, but I no longer remember the rest of the issues in the larger discussion. However, I did not realize that CC mode actually used that case. I thought it had a beginning-of-defun-function. I was surprised just now to see that it didn't have one. Perhaps that should be changed. However, taking out the use of syntax-ppss in beginning-of-defun-raw isn't the right way to get good behavior in CC mode. That would only make it parse from the start of the file every time. 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). Why would it break them? (In any case, such a problem won't arise in Emacs Lisp mode, since open-paren-in-column-0-is-defun-start = t.) 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. Normally I'd expect it NOT to treat nested definitions as defuns. Normally they would be entirely indented. 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. You can get this behavior by adjusting the indentation when open-paren-in-column-0-is-defun-start = t. A reliable way to get behavior 1 is to use syntax-ppss rather than beginning-of-defun. That is a good point. Maybe some uses of beginning-of-defun (such as in Font Lock) ought to use syntax-ppss instead. I think that is orthogonal to the question of this change in beginning-of-defun-raw. The proposed patch basically tries to make beginning-of-defun follow the behavior number 1 and to make it do so reliably. I don't see it that way. 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. I agree, that might be good.