[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: Mon, 20 Jun 2016 15:15:34 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2

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.

reply via email to

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