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

[Richard Stallman <rms@gnu.org>]

    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.