Re: font-locking and open parens in column 0

[martin rudalics]

Good evening, Alan

> The cause of this (as Martin (almost) discerned) is that the handling of
> (eq open-paren-in-column-0-is-defun-start nil) in begining-of-defun-raw
> hasn't been implemented.  The function just looks for a "(" in C0
> regardless of that variable.
>
> "Clearly", when that variable is nil, a defun can begin at no place
> other
> than a paren at the outermost level.  Therefore, the function must scan
> the entire source file from BOB, as in the earliest days.

No!  That would be a serious regression.  Font-locking should never be
forced to scan from BOB.  Observe that this would only serve to handle
the rare case where a user puts a paren in column zero of a C comment.
I think warning about such parens as in emacs-lisp-mode is sufficient.
Please try to make use of Richard's `font-lock-syntax-paren-check' from
this thread as with

    (put font-lock-beginning-of-syntax-function
         'font-lock-syntax-paren-check t)

Moreover, any such code as yours should

(1) Consult `syntax-ppss' first.

(2) Try to use the 9th field of the return value of `parse-partial-sexp'
to find the outermost paren instead of up-/forward-/backward-listing.

(3) Crowd the cache of `syntax-ppss' in order to avoid further scans.