Re: Mysterious fontification/C++ context issue

[Stefan Monnier]

>> Could we set open-paren-in-column-0-is-defun-start to t for c mode?

> This would nullify the fix for the bug reported by Martin a few weeks
> ago, namely: Load syntax.c and immediately jump forward to a certain
> function.  The fontification was seriously wrong.

These limitations have existed for years.   In elisp (and in c-mode at some
point during the development of Emacs-22), we addressed those problems not
by fixing them but instead by highlighting in `warning' face the pieces of
code that can cause such problems.

Such limitations are not necessarily that bad.  After all, if you write your
code in a sufficiently odd way, the indentation engine will also get
completely confused.  Emacs only provides good support for code written in
a sufficiently idiomatic way.

> I think I now agree with Martin R: opic0ids should become a fully user
> settable option, and CC Mode should respect it.

I think I agree.  But I'd do it slightly differently.
The "open-paren-in-col0" is a heuristic that makes sense in some modes but
not all.  Other modes may want another heuristic.

The heuristic itself is currently specified/enabled via
`syntax-begin-function' whose value may use things like beginning-of-defun.
I think the user's control should be on syntax-begin-function (e.g. by
adding a Custom var that forces Emacs to ignore the syntax-begin-function
setting).

> I'm not 100% sure what effect this would have on CC Mode, but it'll be
> something like this: c-beginning-of-defun will continue to look for an
> unnested {, but with (eq opic0ids t), its results will be probabalistic
> rather than rigorous.  But it worked well enough before, when
> beginning-of-defun was a bit squidgy.

And if the user chooses to let the major mode use some heuristic, it'd be
good for the major mode to flag (to the extent possible) those places where
the heuristic is in error.

In the same area: the change in beginning-of-defun which treats
open-paren-in-column-0-is-defun-start specially when defun-prompt-regexp is
nil (and which currently leads to oddball cases where point can end up in
the middle of an parenthesized expression, as shown by Martin's examples)
should be replaced by a new var "b-d-f-check-syntax" which if non-nil causes
beginning-of-defun to skip the false matches (i.e. parens-in-col0 or
defun-prompt-regexp matches that are not at toplevel) by checking
syntax-ppss.


        Stefan