Re: font-lock-syntactic-keywords obsolet?

[Alan Mackenzie]

Hello, Dmitry.

On Mon, Jun 20, 2016 at 10:15:58PM +0300, Dmitry Gutov wrote:
> On 06/20/2016 09:12 PM, Alan Mackenzie wrote:

[ .... ]

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

> Please give an example of syntax-property application in C++ Mode that 
> only happens inside a string. And another, which only happens outside of 
> strings, if there are any.

The criterion was "... whether it's inside a string or commont, among
other things.".  There are syntax-table uses in "other things", namely
macros.  For example, in

    #error don't panic!

the "'" gets punctuation syntax, but wouldn't outside of the macro.

C++ template delimiters (and the like in Java) get parenthesis syntax in
code, but not when in a string.

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

> Stefan already addressed that: 
> http://lists.gnu.org/archive/html/emacs-devel/2016-06/msg00421.html

He sort of addressed it.  The code which implements
syntax-propertize-extend-region-functions is not fully general.  For the
general case, you'd need to supplement such a function with a mode
specific before-change function.  And if you've got to do that, you
might as well just finish the job off and write an after-change function
and bypass the complexity of syntax-propertize-extend-region-functions
entirely.

> But like he said, normally, you just don't.

He's wrong.  You have, say, in C++ "a < b, c > d", which has been given
s-t properties as a template.  You insert "=" after ">".  That
necessitates de-propertising the "<" as well as the ">".

> It's rare to have the syntactic meaning of a construct change based on
> text several lines down from it. Or even just one line.

It happens regularly.  Or, at least, often enough that it's got to be
dealt with, particularly with C++ template delimiters.

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

> b/a-c-f are handy when things are easy?

> Thanks! That's helpful.

They're handy in the usual case.

> > Oh, I'm pretty "educated" about syntax-ppss, thank you very much -
> > educated enough to submit bug reports about it.

> Just one, and you like reminding us about it every chance you can.

I'm hoping that, by doing so, it'll get fixed by somebody who isn't me,
given how much I dislike the function.  Please do fix it, like you
suggested somewhere else today.

> > But I was hoping you
> > could tell me something more about non-"local" s-t properties.

> What's that? Properties can't be non-local. They are just values you put 
> on a piece of buffer text.

<sigh>.  The meaning we've already established over several posts is
syntax-table text properties whose setting, or lack thereof, is
influenced by arbitrarily distant text in the buffer.  You have asserted
that there exist such text properties in Ruby Mode.

> Please ask a specific question.

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

> Meaning, never?

My meaning's clear enough.

Good night!

-- 
Alan Mackenzie (Nuremberg, Germany).