GNU bug report logs - #36136
syntax-ppss fails to invalidate its cache on changes to syntax-table text properties

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 36136 <at> debbugs.gnu.org
Subject: bug#36136: [PATCH]: Re: bug#36136: syntax-ppss fails to invalidate its cache on changes to syntax-table text properties
Date: Thu, 13 Jun 2019 12:21:50 +0000

Hello, Stefan.

On Wed, Jun 12, 2019 at 06:54:25 -0400, Stefan Monnier wrote:
> >> Hmm... I'm not too fond of adding ad-hoc support for specific
> >> text-properties in (set_properties, add_properties, remove_properties).
> > Neither am I, particularly.  But the whole point of syntax-ppss, surely,
> > is that it should work automatically, without users having to call
> > syntax-ppss-flush-cache all the time.

> `grep` seems to argue that "all the time" is an over statement.

CC Mode has to call that function all the time, without any scare
quotes.  In particular, it has to call the thing before each
font-locking action.  It shouldn't have to; it doesn't even make any use
of the package, and is thus messy programming indeed.

The root of the problem is the implicit assumption made by syntax-ppss
that programs would never set syntax-table properties.  This assumption
doesn't hold.

[ .... ]

> > It will probably not make a great deal of difference either way.  Buffer
> > changes are frequent in Emacs, and so are calls to syntax-ppss in many
> > major modes.

> That's also my impression (which is why I haven't bothered to make
> syntax-ppss-flush-cache lazy like your patch does, even tho I've been
> tempted to several times).

> > Well, for CC Mode I'm going to have to do that anyway, since Emacs-26.x
> > and earlier are already out there and aren't going to change.

> Indeed.
> [ unless you decide to make CC-mode use syntax-propertize, of course ;-) ]

I don't think that would work without loss of functionality and loss of
speed (to whatever degree), and even if it could, would be more work than
it's worth.

> But I also agree that it shouldn't prevent us from looking for
> better solutions.

What about my idea of giving a "no inhibit" property to functions on
before/after-change-functions?  This would be easy to implement, though
might have unwanted unexpected consequences.

> > This is going to be tedious and error prone.

> I don't see why.  Usually a single call does the trick (as seen above:
> either in the function that sets the syntax-table property, or in the
> function that takes care of refreshing things in response to a buffer
> modification).

Yes, you're right, it wasn't too bad.  There are many functions in CC
Mode which set the syntax-table property, so adapting each of them
didn't come into consideration.  I amended the existing cache
invalidation routine to keep track of a syntax-table property position,
and pass that position to syntax-ppss-flush-cache at the end of
c-after-change, just before font-lock kicks in.

But, as already said, I shouldn't have to do this.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.