Re: Parens in column 1 equals defun fiasco

-- Matt Tucker <tuck(a)whistlingfish.net&gt; spake thusly: I've been experimenting with this patch (attached to Message-ID <30940000.983237796＠benzene>), and have discovered that it slows down beginning-of-defun considerably when used deep into a large file. This is because the new method does a `parse-partial-sexp' from the beginning of the file each time it's called. This is necessary to properly deal with syntax in a file. However, a consequence of this is a significant performance impact on such functions as `*-indent-command' and `*-indent-exp' (to name a couple). To achieve a performance boost, the `font-lock-fontify-syntactically- region' which I ported from GNU Emacs uses a marker `font-lock-cache-position' and a variable `font-lock-cache-state' to store the most recently parsed-to state of `parse-partial-sexp'. Presumably `beginning-of-defun' could benefit from a similar method. But if I'm going to do that, it occurs to me that perhaps I should just move the functionality into syntax.c and let everything that calls `parse-partial-sexp' take advantage of it. The assumption would be that calls to `parse-partial-sexp' which request scanning from the beginning of the file to a given point without stopping (ie, calls which are attempting to determine the syntax state at a given point) are more likely to be from a later point in the buffer than the last such call. So if `parse-partial-sexp' caches the state each time such a call is made, it could just pick up from that point the next time. Presumably this would also require a way to invalidate the cached state if an insertion/deletion is made to the buffer prior to the cache point (somewhere in buffer.c)? Comments? Does this seem like a worthwhile scheme? Would something else be better?