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

[martin rudalics]

>>Before the changes beginning-to-defun-raw, doing M-> to move to the
>>end of xdisp.c is instantaneous.
>
>
> Hey, that's not fair!  When you raised this problem, you were
> complaining about how slow a M-v was, after having got to EOF.  Is this
> M-v now acceptably fast for you on your 1.7 GHz machine?
>
>
>>With the patch applied, M-> takes four seconds.  This is on a Pentium 4
>>1700MHz computer.
>
>
> It's worth pointing out that this is only the first time.  If you then
> do M-< and another M->, these are then instantaneous.  If (some) cache
> later gets disrupted, then the M-> would be a bit slow again.
>
> 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.

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

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

- implicitly forcing the authors of other tools to abandon the rule as
  well.

If that's the intention, GNU should change the coding standard first.