[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug #25608 and the comment-cache branch

From: Alan Mackenzie
Subject: Re: Bug #25608 and the comment-cache branch
Date: Sat, 18 Feb 2017 10:44:38 +0000
User-agent: Mutt/1.7.2 (2016-11-26)

Hello, Stefan.

On Thu, Feb 16, 2017 at 09:10:44 -0500, Stefan Monnier wrote:
> > It was a case of seeing if two distinct syntax tables were "the same"
> > from the point of view of literals.  In other words, they could parse
> > parentheses, whitespace and so on however they liked, but comments and
> > strings had to be parsed identically by both tables for them to count
> > "the same".

> Interesting.  Indeed, given that syntax-ppss has to pay attention to
> more than comments and strings, equivalence between syntax-tables is
> never something I considered.

For syntax-ppss, two syntax tables are either `equal' or not.  There's
probably no other useful standard of equivalence here.

> > This is an instance where syntax-ppss's ambitions count against it - on
> > any set-syntax-table syntax-ppss's caches should really be cleared,
> > strictly speaking.

> As you know, syntax-ppss's caching is fairly naive currently and doesn't
> make enough checks to give correct results in some cases.  Changes in
> the syntax-tables and in point-min being two examples discussed here.

Another example is modify-syntax-entry, though this is surely less
important, since it will almost always be done at initialisation only.
Zapping the syntax-ppss cache is probably a good way of handling it.

> I already suggested to fix the issue w.r.t point-min by replacing
> syntax-ppss-cache with a table indexed by the value of point-min.
> The same idea could be used for syntax-tables.  I.e. make
> syntax-ppss-cache indexed by the combination of syntax-table and
> point-min.

We'd need to be careful not to fill up too much RAM with these caches,
particularly for different values of point-min.

> Another option is to provide a `with-temp-syntactic-context` macro,
> which would locally bind syntax-ppss-cache to nil.  So code which needs
> to temporarily use a different point-min and/or syntax-table for some
> parsing&navigation work could use this macro to avoid being affected by
> the normal cache as well as polluting the cache.

I'm not too keen on the "using a different point-min for some parsing"
bit.  I suggest, again, using island-start and island-end syntactic
markers (these optionally supply a different syntax table).  These would
enable things like temporarily "narrowing to (what looks like) a
comment" and permanently marking a region as an island (e.g. for
multiple major modes), yet the syntax at any position would be rigorous
and unique throughout the buffer.

> I use this approach of let-binding syntax-ppss-cache in sm-c-mode, for
> example (and yes: it's a dirty hack since sm-c-mode shouldn't mess with
> syntax-ppss's internals).

> Which approach is best depends on the use: If that same syntax-table
> will be reused many times (so caching between uses would be beneficial),
> then indexing by syntax-table in syntax-ppss-cache is likely the better
> choice, otherwise with-temp-syntactic-context is probably all you need.

>         Stefan

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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