Re: font-lock-syntactic-keywords obsolet?

[Alan Mackenzie]

Hello, Dmitry.

On Sun, Jun 19, 2016 at 08:55:52PM +0300, Dmitry Gutov wrote:
> On 06/19/2016 08:15 PM, Alan Mackenzie wrote:

[ .... ]

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

No.  In the current C++ Mode, after-change functions remove the
syntax-table text property from D, ensuring template delimiters balance
always.

> > 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, ....

only when font-lock is enabled.  What about when it's not enabled?

You seem to be advocating that CC Mode should lose its deterministic text
property handling and replace it by a "hope it's OK" non-deterministic
handling.  You can understand me not wanting to do this.

> .... and the current visible area of the buffer is already
> syntax-propertized (this is how this problem was solved in Emacs <25).

There's no guarantee that the matching template delimiter for any given
delimiter is on the screen. It might be after the screen, it might be
before it.

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

Yuck!  That's the sort of ugly workaround that becomes needed when things
aren't properly thought through from the beginning.  In a proper design,
the low level routines in syntax.c wouldn't even know about s-p-function,
and nor should they.

> > 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 [can't :-] be sure that a given position is syntax-propertized.

In CC Mode that certainty exists.  That certainty exists if the
before/after-change-functions are implemented properly.

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

How is it wasteful?  If the syntax-table properties are all "local", it's
actually an efficient way to do things.  You simply have to extend the
(beg end) region to that which might contain pertinent characters, remove
s-t properties in a before-change function, and apply them in an
after-change function.  If the s-t props aren't "local", then maybe the
syntax-propertize-function approach is a good one.  I haven't had any
reason to think this through.  Somebody (either you or Stefan) opined
that ALL s-t properties are, in practice, "local".

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

The current CC Mode before/after-change-function design has been
carefully thought out.  I'm not convinced that's the case for the
syntax-propertize-function mechanism.

> Maybe you would discover an even better design along the way, who
> knows.

Maybe.  But it's not as though I'm short of things to do.

-- 
Alan Mackenzie (Nuremberg, Germany).