[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36136: [PATCH]: Re: bug#36136: syntax-ppss fails to invalidate its c
From: |
Stefan Monnier |
Subject: |
bug#36136: [PATCH]: Re: bug#36136: syntax-ppss fails to invalidate its cache on changes to syntax-table text properties |
Date: |
Wed, 12 Jun 2019 06:54:25 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
>> 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.
I see the following uses in Emacs's bundled files:
- one call in lisp/elec-pair.el [ I think this one would likely be
better handled some other way (e.g. by setting syntax-ppss-table), tho
I haven't looked hard enough to have a firm opinion yet ].
- in before-change-functions, of course.
- one call from syntax-propertize.
- one call in font-lock-apply-syntactic-highlight (this is part of the
font-lock-syntactic-keywords functionality marked obsolete in 24.1).
- one call in fortran-line-length (not because the buffer is changed,
but because the syntax-propertize-function is changed).
Of these, only the one in syntax-propertize and the one in
font-lock-apply-syntactic-highlight would be made unnecessary by your patch.
I see a few more calls in the elpa.git files, but none of them seems
affected either.
> 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 ;-) ]
But I also agree that it shouldn't prevent us from looking for
better solutions.
> 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).
Stefan