emacs-devel
[Top][All Lists]
Advanced

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

Re: font-lock-syntactic-keywords obsolet?


From: Alan Mackenzie
Subject: Re: font-lock-syntactic-keywords obsolet?
Date: Mon, 20 Jun 2016 15:25:36 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Dmitry.

On Mon, Jun 20, 2016 at 03:15:34PM +0300, Dmitry Gutov wrote:
> Hi Alan,

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

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

I hold simplicity to be an admirable thing to aim for.  KISS.

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

Since when has ad hoc calling of high level code from primitives been
"simple and sensible design"?  You'll note that the CC Mode way simply
doesn't need this.

And I say to you quite openly, the continual niggling and nagging I've
been getting over the past months and years to adapt CC Mode to an
way of dealing with text properties I hold to be inferior has got tiring
and draining.  I'd be most obliged if you would stop doing this.

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

True,

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

But that's false.  The text properties get applied on the entire buffer
when it is first opened, and from then on all manipulations are "local".
A change of a s-t property near BOB, say deleting a template opening
delimiter has no effect on the text beyond the next semicolon.

If things had been as you suggest, quite likely I would have come up
with something a bit like syntax-propertize-function, though maybe not
very much like it.

> 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 you still think this is true, and can demonstrate this with a test
case, I will have a look at it and attempt to fix it.

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

We'll see.

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

I'd be interested to hear of some Mode where such shortcuts, as you call
them, aren't available.  syntax-propertize-function is just one way of
handling syntax-table text properties, and it probably uses
before/after-change-functions.  If it doesn't, then there will be
arbitrary periods of time in which the state of the s-t properties is
undefined.  This isn't simple, and I hold it to be non-good.

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

Whatever is needed.  Sorry, but the question is too vague.  Emacs Lisp
Mode, as far as I know doesn't have its own a-c-f, so the answer would
be "nothing".  I don't know Ruby Mode.

The point here is that, mostly, strings don't require s-t text
properties.

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

On non-"local" syntax table text properties?  I don't recall seeing any
discussion of this, except for the one we're now having.  If I've
forgotten it, or missed it, you could perhaps point it out to me.

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

> You're misremembering.

It must have been somebody else, then.  Are you aware of any non-"local"
use of syntax table text properties?

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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