bug#16526: 24.3.50; scroll-conservatively & c-mode regression

[martin rudalics]

> The @dfn{state cache}, a list of certain brace/paren/bracket positions
> around some position, is set for a position near EOB.  With the switch to
> a different position, CC Mode tweaks the state cache rather than
> calculating it anew starting at BOB.  When the new position is nearer
> BOB, the code searches backwards for the appropriate braces.  However, it
> shouldn't be scanning the entire buffer backwards.  There is clearly a
> bug here.

In my scenario `end-of-buffer' should already have produced the complete
state cache.  How else would you have been able to fontify code near EOB
correctly?

> The backward scan-lists calls will be causing continual forward searches
> from BOB in syntax.c, every time the backward scan hits a comment ender.

IIUC now any call to `forward-comment' with a negative argument will
automatically go to BOB unless it's already there.  How else could it
determine that it's not called from a position within a comment?  So if
you decide to bind `open-paren-in-column-0-is-defun-start' to nil, then
why don't you build the state cache anew from BOB?

In any case, please provide an option say
`c-open-paren-in-column-0-is-defun-start' which people can set to avoid
those scans.  The doc-string should mention that things like Michael's
commented out code are handled correctly iff this option is nil and that
long delays while working with c-mode can be sometimes avoided by
setting this option to t.  The default value could be obviously nil.

martin