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

[Alan Mackenzie]

Hi, Martin!

On Fri, Dec 15, 2006 at 08:32:53AM +0100, martin rudalics wrote:
> Good morning, Alan

> > In normal, carefree use, an open paren/brace in column 0 doesn't
> > happen that often.  A typical user won't notice when a M-q in a
> > string puts a ( at column 0, so when the fontification goes awry,
> > it's a big jolt, and an indefinite time sink to sort out (or ignore)
> > the problem.

> At the time I noticed the bug it indeed took me some time to find its
> cause.  That's why I convinced Richard to write a tiny patch which now
> allows me to highlight offending parens in C mode appropriately.
 
Yet we're Emacs experts.  I think we're placing too little importance on
the shock and emotional distress that such a bug [totally hosed
fontification over an entire screen] will cause an ordinary Emacs user.
Even highlighting these parens might well puzzle, rather than help, this
user.

[ .... ]

> I don't mind if C mode sets this to nil by default.  I do mind,
> however, if things break when I set this to t in my c-mode-hook.  Your
> earlier remark that c-beginning-of-defun function "depends essentially
> on beginning-of-defun working "correctly" (i.e. syntactically) when
> opic0ids is set to nil" is not entirely reassuring in this respect.

It wasn't a very bright thing for me to say.  I think I meant for a
fully general source file, including syntaxes.c.  For a file without a (
in C0, it shouldn't be important.  Sorry, and thanks for calling me on
that one.

> Hence please tell me: Does `c-beginning-of-defun' work correctly when
> I set `open-paren-in-column-0-is-defun-start' to t?  If you say it
> does, I can (1) speed-up fontification of C buffers _and_ get
> information about potential mis-fontification by setting

Yes, as long as its not syntax.c.

> (set (make-local-variable 'open-paren-in-column-0-is-defun-start) t)
> (put font-lock-beginning-of-syntax-function
> 'font-lock-syntax-paren-check t)

I'm a bit confused at the moment.  I'll pass on that one for now.

> in my `c-mode-hook' and (2) get correct albeit slow fontification by
> not doing so.

> In general, we could make (1) the standard for users leaving alone the
> default value of `open-paren-in-column-0-is-defun-start' and (2) the
> standard for users who customized that to nil.  Until, eventually,
> `open-paren-in-column-0-is-defun-start' is made obsolete.

"Until" ??

[ .... ]

> > Most of them neither know nor care about the GNU rule.  I don't know
> > of any program (aside from Obfuscated C entries) where programmers
> > knowingly put { or ( in C0 (apart from defun openers).  It's
> > something that just happens, much as it did in syntax.c.

> I should have said "less and less programmers care about not putting
> parens that do not start defuns in the leftmost column" (the paren in
> syntax.c is still there).

It's gone, now.  Still, that mere fact that it was there at all
demonstrates how difficult it is to avoid these things entirely.

[ .... ]

> If the purpose of that entry in GNU standards is to enforce a rule for
> Emacs users only and C mode does not care about it ...

I think the rule was pure optimisation - to allow Emacs to work at a
tolerable speed when processor speeds were measured in single or double
digits, the units being MHz.

[ .... ]

> But you agree that, if tools are not able to do so easily, we should
> not encourage people to write programs that do not follow the
> standard?

For some value of "encouragement".  ;-)  I would say, rather, we should
attempt not to penalize people into whose files a columnd 0 ( strays.

Maybe, as Chong has said, the time is not yet ripe.

-- 
Alan.