[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: font-locking and open parens in column 0

From: martin rudalics
Subject: Re: font-locking and open parens in column 0
Date: Thu, 02 Nov 2006 19:31:32 +0100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]