[Top][All Lists]

[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

OK.  It's difficult.

>         Stefan

Alan Mackenzie (Nuremberg, Germany).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]