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

[Alan Mackenzie]

Hello, Eli.

Thanks for criticising my proposed patch.

On Sun, Jun 09, 2019 at 08:56:45 +0300, Eli Zaretskii wrote:
> > Date: Sat, 8 Jun 2019 20:36:39 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > > Suggested fix: the functions set_properties, add_properties,
> > > remove_properties in textprop.c should check for changes to,
> > > specifically, syntax-table properties.  When these changes are detected,
> > > a hook called something like syntax-table-props-change-alert-hook should
> > > be called (with some appropriate position parameters, tbd).
> > > syntax-ppss-flush-cache will be added to this hook.

> > Here is a first draught of a fix to this bug.

> I have no opinion about the issue and the idea of its proposed
> solution, but I do have some comments to the implementation.

[ .... ]

> This means that whenever syntax.el is loaded (i.e., always, since
> syntax.el is preloaded), this hook will be non-nil.  Is that a good
> idea?  I mean, if we always call this function, why do this via a
> hook?

No, it's not a good idea.  Mainly because of ....

[ .... ]

> Also, what about the safety of this call? what if the hook signals an
> error or the user presses C-g while the hook runs?  IOW, should you
> use safe_call or some of its variants, and should you inhibit QUIT?
> and if so, whether and how should you handle in the code the case when
> the hook does signal an error?

.... add-text-properties and friends are called from redisplay.  So it
would be particularly inconvenient for a hook function to throw an error
here - some sophisticated error handling (like there must be for
fontification-functions) would be needed.

You're right.  All that the hook function really needs to do is set some
buffer local syntax-ppss variable indicating the maximum valid position.
This doesn't need a hook, just a new variable in syntax.c and code there
and in syntax-ppss to use it.

[ All other comments noted, and to a large extent incorporated into the
code.]

So, I'll start again.  Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).