Re: generic buffer parsing cache data

[martin rudalics <rudalics@gmx.at>]

 > It is unclear whether changes in any text properties should lead to cache
 > invalidation.  Probably no, at least by default.

Maybe for changes in syntax-table text properties.

 > It also makes sense to define some `anchors'.  Those would be ways of
 > partitioning buffers into parts, where changes in one part don't cause
 > invalidation of cache data in other parts.  For instance, in Python mode
 > anchors would be set wherever a toplevel block is defined, since it stops
 > parsing on reaching a toplevel anyway.  However, this can be added later.
 > For instance, it is not clear when and how to remove anchors.  (I.e. in
 > Python mode if toplevel is indented to another level, it should stop
 > being an anchor.)

An open-paren-in-column-0 would be such an anchor in many modes.

 > It is required that major mode stores cache data at some logical position,
 > so it can later find them again.  Maybe it also makes sense to add
 >
 >     Function: find-cache-data key &optional pos
 >
 > 	Find and return cache data at POS (or point position) or _before
 > 	it_.  Return nil if there is no (valid) cached data at pos or
 > 	anywhere before with that KEY.

The classic method based on the entire information to get out of a
nested block.

 > However, I don't see any obvious ways of using it.  As I can see, modes
 > should access cache data like this (in pseudocode):
 >
 > 	mode-get-cache-data:
 > 	    data = (get-cache-data mode-key)
 > 	    if data is nil:
 > 		data = (mode-compute-cache-data)
 > 		(put-cache-data mode-key data)
 > 	    return data
 >
 > 	mode-compute-cache-data:
 > 	    save-excursion:
 > 		travel-to-higher-level-cache-point
 > 		higher-level-data = (mode-get-cache-data)
 > 	    data = (mode-compute-data-from-higher-level higher-level-data)
 > 	    return data
 >
 > Here `higher-level' is not the same as `previous'.  For instance, in
 > Python mode it makes sense to compute indentation from the block this one
 > is nested in, not just previous block:
 >
 >     class X:
 > 	class Y: # <-- higher-level block for the current block
 > 	    class Z:
 > 		def bla (): # <-- previos block (with cached data)
 > 		   pass
 > 	    def __init__(self): # <-- current block
 > 		pass

I don't see why it should be difficult to keep the entire necessary
information at "bla".  After all you'd avoid to compute your data from
"class Y".  Moreover in other contexts it's not clear whether a thing
like "class Y" does constitute a "higher-level" block than the current
one.

Anyway, I understand that you want some routines for cache management
where the major (or minor) mode would fill in the necessary information
itself.  I don't see any problems adding such functionality to
`syntax-ppss' as Stefan suggested.