[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Syntax-ppss flush should happen in after-change hook
From: |
Vitalie Spinu |
Subject: |
Re: Syntax-ppss flush should happen in after-change hook |
Date: |
Sat, 16 Mar 2019 18:35:09 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
>> On Sat, Mar 16 2019 11:53, Stefan Monnier wrote:
>> Currently ppss flush happens in before-change hook. This leads to a real
>> possibility that syntax-propertize is called before the actual change and not
>> refreshed after the change. This could occur in at least two scenarios.
>>
>> First, when a hook placed after syntax-ppss-flush-cache in
>> before-change-functions invokes `syntax-propertize` (for example with a
>> search).
> If syntax-ppss-flush-cache is on after-change-functions then the risk is
> when a hook function is placed before it.
So it's inconsistent state for the hooks vs inconsistent state for all the emacs
functions after the change.
> Given the fact that add-hook defaults to placing functions at the head and
> that after-change-functions are much more commonly used than
> before-change-functions
One simple solution is to add a sentinel to the before-change-functions to
explicitly check for syntax-ppss-flush-chache being the first hook:
(unless (eq (car after-change-functions) 'syntax-ppss-flush-cache)
(delq 'syntax-ppss-flush-cache after-change-functions)
(add-hook 'after-change-functions 'syntax-ppss-flush-cache nil t))
> A crude solution could be the ad-hoc hack below. We could make it less
> ad-hoc by adding a way for any hook function (on b-c-f and a-c-f) to
> indicate whether it should stay active within combine-change-calls,
> e.g. with a symbol property `do-not-combine-change-function`.
AFAICS this will not help with the main part of the problem (second scenario in
OP). The problem is not that some inconsistent state happens during the
combine-change-calls but that after the change ppss is left in inconsistent
state. Combine-change-calls happened in my example, but currently any buffer
change results in inconsistent syntax state.
As far as I understand, just before the actual change the cache is in consistent
state, so currently, if the changing function requires syntax properties then
before-change flush enforces extra syntax-propertize for nothing. In my example
that search need not have had triggered syntax-propertize would the flush not
have had happened.
Vitalie