Re: AW: font-locking and open parens in column 0

[Stefan Monnier]

>     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