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

[Alan Mackenzie]

Grüßle Göttle, Martin!

On Thu, Dec 14, 2006 at 11:47:59AM +0100, martin rudalics wrote:
> >>Before the changes beginning-to-defun-raw, doing M-> to move to the
> >>end of xdisp.c is instantaneous.

[ .... ]

> > Do you have any idea why M->, which is surely nothing more than
> > (goto-char (point-max)) is so slow?  I have an idea it is the
> > filling of CC Mode's cache.
 
> M-> ran almost instantaneously before `beginning-of-defun-raw'
> changed.  And you did fill CC Mode's cache already before the change.
> I could imagine it's because font-locking runs `beginning-of-defun'
> repeatedly for decreasing buffer positions and the `syntax-ppss' cache
> doesn't handle these cases optimally.

You're probably right, there.

> > It isn't only Emacs source files.  It happens a lot in normal users'
> > files.c.  There's a FAQ about it in the CC Mode manual.  After all,
> > having parentheses inside strings and comments in C is perfectly
> > valid and acceptable syntax, and it looks like a bug (which indeed
> > it is), if Emacs can't fontify such things properly.

> That statement is not fair either: Nobody doubted the validity of
> parentheses inside strings and comments.  The problem is due to
> non-escaped parens in the leftmost column that do not start a defun.
> Such parens do not follow GNU coding standards (Section 5.5.1, as of
> November 15, 2006):

>     It is important to put the open-brace that starts the body of a C
>     function in column one, and avoid putting any other open-brace or
>     open-parenthesis or open-bracket in column one. Several tools look
>     for open-braces in column one to find the beginnings of C
>     functions. These tools will not work on code not formatted that way.

We're down to philosophy/politics, here.  Lots of CC Mode users,
probably most, are not working on GNU projects - Linux hackers, for
example, to say nothing of thousands (?hundreds of thousands) of
programmers working in their day jobs.  We shouldn't be ramming GNU
standards down their throats - they should have the freedom to accept or
ignore these.

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.

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".

Comments, please!

> If C mode were to weaken that rule we'd end up in a situation where

> - 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.

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.

> - 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?  ;-)

> 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.

-- 
Alan.