Re: font-lock-syntactic-keywords obsolet?

[Dmitry Gutov]

On 06/19/2016 08:15 PM, Alan Mackenzie wrote:

> Yes, that is indeed the case.  Sorry I didn't spot that earlier.  The
> same applies to an ordinary string, too, provided there are enough
> escpaed new lines.

So some operations in CC Mode are indeed O(buffer length)? That sounds 
like a problem.

> > > A critical reason, which I've told you before, is that on any buffer
> > > change, the syntax-propertize-function mechanism blasts all s-t
> > > properties out of existence from the point the change is made onwards.
> > > This is wasteful of run-time, given that these properties are quite
> > > expensive to apply.
>
> > They can't be too expensive, considering other language modes, which do
> > use syntax-propertize-function, exhibit fewer performance problems than
> > CC Mode, even at the same file sizes.
>
> The speed problems with CC Mode are not to do with the way it puts text
> properties on characters.  Anyway, that's recently got better.  :-)

My point is, the "critical reason" can't be too critical, considering 
you've been living with bigger problems for quite a while.

> > And if the automatic removal of syntax-table properties would lose
> > important information, you could save them to a separate structure.
>
> I could, but why go to all the hassle when handling these properties in
> before/after-change-functions works so well?

Is O(buffer length) "working well"?

> Consider the following non-unusual case.  In C++ Mode we have nested
> template delimiters, thusly:
>
>     A       B     C          D
>     <       <     >          >
>
> They each have parentheses syntax-table text properties such that A
> matches D and B matches C.  You can, for example put point at A, do
> C-M-n, and you will get to after D.
>
> Suppose you delete the < at A, and move point to D.  What will now
> happen if you do C-M-p?

Scan error?

> With a syntax-propertize-function instead of the current
> before/after-change-functions, I simply can't picture what would happen.

The same.

a) By the time you move point to D, font-lock has most likely run, and 
the current visible area of the buffer is already syntax-propertized 
(this is how this problem was solved in Emacs <25).

b) In addition to that, scan_lists now applies syntax-table properties 
by calling syntax-propertize-function

> Why do we need
> such a general abstraction, anyway?  before/after-change-functions
> already form a good scheme for applying and removing these properties.

Because just by the virtue of having before/after-change-functions, we 
can be sure that a given position is syntax-propertized.

The only way we could, without adding additional abstraction, is by 
agreeing that all buffers must be syntax-propertized in their entirety 
after before/after-change-functions run. And that is just too damn wasteful.

> Changing CC Mode to use syntax-propertize-function would require a
> substantial amount of design work, assuming such were possible.  There
> doesn't seem to be a good reason to do this.

One reason would be for you to get a handle on what it does, and the 
design benefit that follow. Maybe you would discover an even better 
design along the way, who knows.