[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Syntax-ppss flush should happen in after-change hook
From: |
Stefan Monnier |
Subject: |
Re: Syntax-ppss flush should happen in after-change hook |
Date: |
Sat, 16 Mar 2019 14:09:37 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
> 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))
That would require using both b-f-c and a-f-c.
I'd much rather "do it right" and change add-hook to understand a notion
of depth/priority/order.
>> 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.
I believe it does help the problem at hand: the final state of the cache
will be correct (and the state of the cache is correct during the
combine-change-calls as well).
> Combine-change-calls happened in my example, but currently any buffer
> change results in inconsistent syntax state.
Then I must have misunderstood something.
Can you give more details about the problem scenario you have in mind?
> 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
At the level of b-c-f and a-c-f the only "changing functions" are things
like `insert` or `delete-region` and they should not trigger
syntax-propertize or syntax-ppss (other than via b-c-f and a-c-f,
obviously).
It's only when you start using combine-change-calls (or
combine-after-change-calls) that the code the performs the change
between a-c-f and b-c-f can run arbitrarly fancy Elisp code.
> 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.
But the search is not done as part of the "change function", so (modulo
combine-change-calls) it either done before b-c-f or after a-c-f, never
between the two.
Stefan