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

[Alan Mackenzie <acm@muc.de>]

Hi, Martin!

On Sat, Dec 16, 2006 at 11:17:20AM +0100, martin rudalics wrote:
> > ... I would say, rather, we should
> > attempt not to penalize people into whose files a columnd 0 ( strays.
> 
> One nice thing about the left-margin convention is that stray parens in
> column zero have localized effect only.  When I have to rely on the
> correctness of the entire syntax of my buffer in order to get reasonable
> syntax-highlighting editing will get tedious: Suppose I deliberately
> introduced some mis-balanced paren near the top of the buffer and to fix
> that case I want to patch some code from the end of the buffer.  I would
> feel penalized.

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.

Users may well want something like this in their c-mode-common-hook:

(if (< (- (point-max) (point-min)) 100000)
  (setq open-paren-in-column-0-is-defun-start nil))

, so the implemention of opic0ids code in beginning-of-defun-raw should
stay, IMAO.

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.

-- 
Alan.