Re: font-lock-syntactic-keywords obsolet?

[Alan Mackenzie <acm@muc.de>]

Hello, Dmitry.

On Mon, Jun 20, 2016 at 07:45:06PM +0300, Dmitry Gutov wrote:
> On 06/20/2016 06:25 PM, Alan Mackenzie wrote:

[ .... ]

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

> Emacs low-level code runs quite a few hooks already, which are 
> implemented in Lisp. You'll also note that the whole Lisp runtime is 
> called from low-level code.

You're evading the point.  There's a difference between a well designed
interface from low to high (of which there are many in Emacs) and "oh, in
this circumstance we might not have syntax table properties current.
Tell you what, we'll bung a call to syntax-propertize into the lowest
level of the syntax routines, that will surely work most of the time".

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

> I wouldn't be in that discussion (or the ones like it) if you just 
> stayed inside CC Mode and didn't try to push new abstractions, poorly 
> designed and duplicating what syntax.el already does, into Emacs core.

Don't be so cheeky.  I'm part of the Emacs team and pushing abstractions,
new or otherwise, is one of the things I do.  Pointing out that syntax.el
is just one of several ways of doing what it does is also something I do;
somebody's got to do it, after all.

[ .... ]

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

> I believe I explained the problem quite clearly. But if you're asking 
> for a test case for CC Mode, I don't care for it.

It's worth noting you labour under some misconceptions as to what CC Mode
does and how it does it.

> This discussion is about general facilities, after all.

Yes.

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

> ruby-mode, for instance. And, like already pointed out, any language 
> where (these requirements are sufficient, but not all necessary):

> - Double-quoted strings are allowed to span multiple lines.
> - Syntax is complex enough that we need to use the syntax-table property.
> - Whether a character gets a syntax-property applied, depends on whether 
> it's inside a string or comment, among other things.

All of these 3 criteria apply to C++ Mode, yet there's no need for lazy
syntax-table propertification there.

Another question for you.  Under the aforementioned laziness, how and
when do syntax-table properties get modified after a buffer change when
these s-t properties are _above_ the position of the change in the buffer?

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

> Why don't you do us all a favor and educate yourself about other 
> languages and language modes before arguing that 
> before/after-change-functions can be a general solution as-is?

I can argue that because they're clean, well understood abstractions.
And I do argue that b/a-c-f are a good way of manipulating s-t properties
when these properties are "local".

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

> Some don't, some do. Heredoc strings do.

> But text outside of strings often does need text properties. And their 
> application depends on whether given text is inside a string.

Yes.

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

> On syntax-ppss. Participating in discussions about a subject is usually 
> a good reason to educate themselves about it. For most people, at least.

Oh, I'm pretty "educated" about syntax-ppss, thank you very much -
educated enough to submit bug reports about it.  But I was hoping you
could tell me something more about non-"local" s-t 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.

> Non-locality is one of the obvious reasons for syntax-propertize's 
> design, the way that syntax-table application is performed lazily.

And it's a good reason not to use syntax-propertize when all s-t
properties are, in fact "local", and it is desirable for these properties
to be amended instantly on buffer changes.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).