Re: font-lock-syntactic-keywords obsolet?

[Dmitry Gutov]

Hi Alan,

On 06/20/2016 01:58 PM, Alan Mackenzie wrote:

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

Option b.

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

You seem to be unable to understand any determinism semantics that are 
slightly more complex than the ones you are working with now.

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

The way you choose to refer to this simple and sensible design as "ugly 
workaround" is incredibly annoying. Please keep that in mind when I stop 
replying.

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

Imagine a big file. You open it and start editing near the beginning. 
With s-p-f, Emacs only has to syntax-propertize it in a limited area 
near the beginning, the rest of the file is completely ignored.

If you jump to the end, the whole file is syntax-propertized once, and 
then, again, as you keep working, only a small area gets re-propertized 
as long as you don't jump far away.

Without s-p-f, you have to keep the whole file up-to-date at all times, 
and that means going over its entirety when the user edits something 
near the file's beginning that affects the parse state of the rest of 
the file, e.g. opening or closing a string, or a block comment.

You could try adding kludges to that, but ultimately, if you want the 
file to always be up-to-date in its entirety, eagerly, you're forced to 
make many operations slower than they have to be.

> If the syntax-table properties are all "local", it's
> actually an efficient way to do things.

In CC Mode you have it easier: strings are limited to one line, or their 
extents are obvious by escaped newlines, and an unclosed block comment 
will get closed at the end of the next block comment.

Even so, you have raw strings now, and with them you're forced to make a 
choice between being fast and being correct.

The shortcuts available to CC Mode aren't something all language modes 
can use, so syntax-propertization through before/after-change-functions 
cannot become the standard. s-p-f can, on the other hand, and already is.

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

Imagine a language with multiline strings (you can call it "Ruby", or, 
maybe, "Emacs Lisp"), and a big file that contains at least one string 
per every ten lines. The user goes to the first string and removes its 
closing delimiter.

What's your after-change-function going to do?

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

The zillion email messages on the subject still haven't encouraged you?

> Somebody (either you or Stefan) opined
> that ALL s-t properties are, in practice, "local".

You're misremembering.