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: Mon, 13 Nov 2006 12:16:22 -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 1163438281 22378 80.91.229.2 (13 Nov 2006 17:18:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2006 17:18:01 +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 Mon Nov 13 18:17:58 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 1GjfQN-000067-02 for ged-emacs-devel@m.gmane.org; Mon, 13 Nov 2006 18:16:47 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GjfQM-0007NB-6H for ged-emacs-devel@m.gmane.org; Mon, 13 Nov 2006 12:16:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GjfQ6-0007Mr-PF for emacs-devel@gnu.org; Mon, 13 Nov 2006 12:16:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GjfQ4-0007M0-0w for emacs-devel@gnu.org; Mon, 13 Nov 2006 12:16:30 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GjfQ3-0007Lx-TJ for emacs-devel@gnu.org; Mon, 13 Nov 2006 12:16:27 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GjfQ2-00048D-R2; Mon, 13 Nov 2006 12:16:26 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 693AE2CEF9C; Mon, 13 Nov 2006 12:16:26 -0500 (EST) Original-Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 329423FE0; Mon, 13 Nov 2006 12:16:22 -0500 (EST) Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 1C5E54C6D25; Mon, 13 Nov 2006 12:16:22 -0500 (EST) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Sun\, 12 Nov 2006 00\:14\:52 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.90 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca 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:62229 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. [...] > 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. This is not what I'm suggesting: I'm saying that the places in cc-mode which use beginning-of-defun-raw in order to find a safe parsing spot should be changed to use syntax-ppss for that instead. This is separate from whether or not beginning-of-defun uses syntax-ppss. > 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? Because the whole point of using them is to avoid parsing from the beginning of the buffer. Maybe it won't burp (depending on how the circular dependency "syntax-ppss => syntax-begin-function => beginning-of-defun => syntax-ppss" works out), but it will at least break the intent of the code. > 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. That strongly depends on the language. In languages such as Standard-ML, it's pretty common to have big functions defined inside others. It's probably true of many languages which use locally defined recursive functions instead of loops. In those languages it's not necessarily useful for beginning-of-defun to only consider toplevel defuns (since there will often only be one or 2 in teh whole file). > Normally they would be entirely indented. Yup. The whole file is indented, basically. > 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. But you may not want to fiddle with the indentation just for C-M-a to jump the way you like it. And the language may not allow you to either (e.g. Haskell where indentation is significant). > 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. Font-lock doesn't use beginning-of-defun. Some clients of font-lock tell syntaxx-ppss (via syntax-begin-function) to use beginning-of-defun as a heuristic, for performance reasons. E.g. emacs-lisp-mode. Those are not interested in beginning-of-defun becoming 100% reliable, since they specifically trade the 100% reliability (which they'd get if they just left syntax-begin-function alone) for speed. > I think that is orthogonal to the question of this change > in beginning-of-defun-raw. That's odd. The need for that change comes straight from such a "use beginning-of-defun to find a safe parsing spot", and the impact of such a change is mostly going to be on similar uses. Stefan