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

From: martin rudalics <[email-masked]>
Date: Sun, 29 Jun 2014 18:01:58 +0200

> 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