Re: font-lock-syntactic-keywords obsolet?

[Dmitry Gutov <dgutov@yandex.ru>]

On 06/20/2016 06:25 PM, Alan Mackenzie wrote:

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

Too bad you have to work on CC Mode, then.

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

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

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

Things are like I say. Maybe not quite for CC Mode, but they are for 
many languages around 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.

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.

This discussion is about general facilities, after all.

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

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

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

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

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

Maybe if you haven't been busy writing shallow critique and asked 
questions instead, we'd gave gotten to this a lot sooner.

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

Yes. And I've been telling you about them for the last several messages.