Re: font-lock-syntactic-keywords obsolet?

[Alan Mackenzie]

On Sun, Jun 19, 2016 at 06:50:26PM +0300, Dmitry Gutov wrote:
> On 06/19/2016 06:34 PM, Alan Mackenzie wrote:

> >> What's a "logical line"?

> > What you get when you resolve the escaped new lines, or the non-escaped
> > new lines inside a C++ raw string.

> But when the raw string is unclosed, it stretches until the end of the 
> buffer, doesn't it? Hence, the effects of adding or removing a closer 
> must affect the buffer until its end.

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.

> > There's no reason to do so, and it would cost a lot of time.  The
> > syntax-propertize-function stuff just isn't a good way of impelementing
> > CC Mode.

> > 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.  :-)

> 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?

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?  At the moment, D no longer has a s-t property,
so it will not (mis)match any other character with paren syntax.

With a syntax-propertize-function instead of the current
before/after-change-functions, I simply can't picture what would happen.
The syntax-table properties would get removed from B, C, and D at some
indeterminate time.  You'd then have a race condition as to whether D
would match or mismatch some indeterminate character before A.

> Anyway, you're welcome to propose an alternative general abstraction for 
> the same kind of thing than syntax-propertize does. 
> font-lock-syntactic-keyword is definitely not that.

No, it's not.  Neither is 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.

> >> Maybe you'll need to hand-implement the logic corresponding to
> >> syntax-propertize-rules, but that's just work.

> > In this context, both "just" and "work" are curse words.  :-)

> "just implementation work", then. As opposed to "design and implementation".

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.

-- 
Alan Mackenzie (Nuremberg, Germany).