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

[martin rudalics]

> scan-lists, a primitive, must be utterly robust.  syntax-ppss is too
> fragile to be used here without a lot of hardening.
>
> syntax-ppss's cache is rendered invalid at any operation which changes
> the syntax table (e.g. `modify-syntax-entry'), or changes to a different
> syntax table (e.g. `with-syntax-table'), or when a syntax-table text
> property/overlay is applied to the buffer, or even when a symbol's
> property list is changed when that symbol is the value of a category
> text property.  CC Mode does all these things, and does all of them
> apart from the first during run time, not merely at mode initialisation.

How can any of these affect the cached start position of a defun before
the position where the buffer contents were changed?

> Also, the syntax-ppss cache's functioning is dependent upon
> before-change-functions, which can be bound to nil by any program at any
> time.

There's an appropriate advice what to do in such case.

> If one were to harden syntax-ppss against all these things, one would
> probably end up calculating the cache from scratch every time, in
> effect.

Can you give an example?

> scan-lists is a primitive, and must function correctly regardless of any
> trickery which might be played on it.

You can easily play trickery on `scan-lists' if you start it within a
comment or string.  So `syntax-ppss' is at least as primitive as
`scan-lists' (especially when the latter is used with negative COUNT).

Anyway, IIUC this implies that CC mode can't work with `syntax-ppss' at
all.  If that is true, then `open-paren-in-column-0-is-defun-start' was
indeed the last resort that made editing larger files possible.

martin