bug#36136: [PATCH]: Re: bug#36136: syntax-ppss fails to invalidate its cache on changes to syntax-table text properties

[Stefan Monnier]

>> >> 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.

IIUC the end of your message, you did find another spot where to call
syntax-ppss-flush-cache, making it much less problematic, right?

> 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.

AFAIK CC-mode is the only exception nowadays.

>> 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?

I'm not convinced this won't introduce more problems than it intends to
fix (it seems that it will likely lead to the subsequent introduction of
a `no-really-I-do-mean-inhibit-all-this-time` etc...).

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

I agree that it would be nice to invalidate the cache in a more
"automatic" way.  But it's a trade-off.  Your new call to
syntax-ppss-flush-cache brings the count of calls that we could
eliminate this way to 3 (one of those being obsolete since 24.1 should
likely disappear soon).  That's still not very many.  And those calls
are pretty efficient I think compared to the more general code which
catches every text-property change to see if it happens to change the
`syntax-table` property.

So the current situation is not ideal conceptually, but it's more
efficient than the alternative both in terms of run-time complexity and
in terms of code size.  It's actually a pretty good deal.
Especially since even with a more automatic approach, there'd still be
other places where we need to call it manually anyway
(e.g. fortran-line-length).


        Stefan