[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: font-lock-syntactic-keywords obsolet?

From: Dmitry Gutov
Subject: Re: font-lock-syntactic-keywords obsolet?
Date: Sun, 19 Jun 2016 20:55:52 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]