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

[martin rudalics]

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.

> I say we should GIVE THE USER THE CHOICE.  I have proposed a way of
> doing this to which nobody's commented yet:  Have three values for the
> variable with the furlong long name, namely (t nil mode).  t and nil
> will carry on meaning what they mean, and the symbol 'mode, the default,
> will mean "Major mode may set its own default here".

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.

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

(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)

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.

>>- more and more programmers put parens that do not start defuns in the
>>  leftmost column (after all the GNU editor doesn't complain and they
>>  already pay with their CPU time for that extra service), thus
>
>
> They do that already.  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).

> Now that we've got 1 to 4 GHz processors, (eq opic0ids nil) is a
> reasonable default for C.  If we can just agree on a mechanism, I will
> amend cc-mode.el to avoid forcing the sluggishness down people's
> throats.  I actually feel quite guilty about that, believe it or not.

I already feel quite guilty for you feeling guilty.

>>- implicitly forcing the authors of other tools to abandon the rule as
>>  well.
>
>
> They will be experiencing the same hiccups as Emacs.  By the way, what
> other tools?  ;-)

That's what I wanted you to ask.  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 ...

>>If that's the intention, GNU should change the coding standard first.
>
>
> I think that's a separate issue.  Maybe these other tools could now be
> adapted to recognise parens inside strings and comments, now that
> processors are fast.  Maybe not.

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?