Re: Mysterious fontification/C++ context issue - Patch for beginning-of-defun-raw.

[martin rudalics]

Hi Alan

> OK, you've convinced me.  I now agree with you that CC Mode should not
> itself set that horrible variable to nil, not even as a default.  I
> should remove the offending line from cc-mode.el, and put some extra
> explanation into cc-mode.texi and programs.texi.

Thank you.  I appreciate this as a wise and thoughtful step.

Here I want to apologize for accusing your `beginning-of-defun-raw'
change as the culprit of the misbehavior of C mode fontification over
the past weeks.  I really should have noticed the misbehavior before
when doing a `scroll-down', `backward-sexp', or `recenter' with a
negative argument.

I'd also kindly ask everyone to not argue against Alan's change any
more.  As far as I can tell from here, the misbehavior is caused by a
deficiency in back_comment when `open-paren-in-column-0-is-defun-start'
equals nil.  Alan's change simply revealed the misbehavior when jumping
to the end of a large buffer.

Using the default value for `open-paren-in-column-0-is-defun-start'
should make all operations in C mode sufficiently fast for the release.

> Another possibility would be a new option in CC Mode (probably
> implemented as a Clean-Up), which would guard against rogue (s and {s in
> column 0.  Were this to be switched on, c-electric-paren,
> c-electric-brace, and the filling routines would insert a \ at column 0
> when needed.
>
> The available evidence is that hackers cannot be expected to notice and
> correct these things without help.

Putting a `font-lock-warning-face' on such parens should be sufficient
for the moment.