Re: font-locking and open parens in column 0

[martin rudalics <rudalics@gmx.at>]

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.