[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#20352: Factor 2 slow down of font-locking in c-mode
From: |
Alan Mackenzie |
Subject: |
Re: bug#20352: Factor 2 slow down of font-locking in c-mode |
Date: |
Mon, 4 May 2015 10:33:38 +0000 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Hello, Stefan.
On Sun, May 03, 2015 at 10:13:48PM -0400, Stefan Monnier wrote:
> > Indeed. Some while ago, you were musing on putting syntax-ppss, or
> > equivalent, into syntax.c, thus rendering
> > open-paren-in-column-0-is-defun-start unnecessary and obsolete. This
> > would speed up or improve the accuracy of, in particular, back_comment
> > and the stacks of things which depend upon it.
> > Is this enhancement still intended?
> Not in the short term, no. I've toyed with it, but there's a problem:
> syntax-ppss's caching relies on the syntax-table being constant.
> This usually works fine because the callers "know" to call syntax-ppss
> outside of with-syntax-table (I guess in reality they don't really know,
> but they happen to do that because they call syntax-ppss fairly early
> on), but it's not uncommon for Elisp code (definitely including CC-mode)
> to use with-syntax-table around calls to forward-sexp/comment, so
> calling syntax-ppss implicitly from within those functions exposes this
> underlying syntax-ppss limitation.
Ah. That sounds like a shame.
> IOW, it can't be done until we figure out how to make syntax-ppss handle
> syntax-table changes.
How about having an association list of ((syntax-table . cache) ...), or
something like that? Each cache would need its own value of the
equivalent of `syntax-propertize--done'. `modify-syntax-entry' would
need to wipe the cache. Then there are `category' text
properties/overlays which might affect the syntax. And so on. And so
on.
OK. It's difficult.
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).