Re: font-locking and open parens in column zero

[Richard Stallman]

    It's the standard paren-in-column-zero problem which is decribed in the
    manual and not considered a bug in Elisp fontification either.  I think,
    it should happen as frequently for C as it happens for Elisp.

That seems unlikely to me.  In my (small) experiments
I did not observe this to happen at all.  You've said it
can happen, and I will take your word for it, but it appears
to be unusual in practice.

      Hence a
    warning face for such parens could be useful just as it is for Elisp.

I suppose so -- and isn't the feature available for C?
When Emacs does get confused about a ( in C mode,
does it show that ( in red?

My point is that the ( usually does not appear in red
because Emacs usually does not get confused by it.

       ;; In Emacs 21 and later it's possible to turn off the ad-hoc
       ;; heuristic that open parens in column 0 are defun starters.  Since
       ;; we have c-state-cache, that heuristic isn't useful and only causes
       ;; trouble, so turn it off.

    That motivation is strange

The reason for C mode to set this to nil
is that C mode specifies its own way to find the start of a defun.
My understanding is that if open-paren-in-column-0-is-defun-start is t
then Emacs will ALWAYS look back for the last ( in column 0.
This is clearly wrong for C mode.


    That motivation is strange since, if the c-state-cache does not contain
    anything useful, C mode has to use `beginning-of-defun'.

Are you saying that this is the case where C mode fails to be
sophisticated about finding the start of the function?

Is that a bug in CC mode?