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: Dmitry Gutov
Subject: Re: font-lock-syntactic-keywords obsolet?
Date: Mon, 20 Jun 2016 22:15:58 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2

On 06/20/2016 09:12 PM, Alan Mackenzie wrote:

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

It will work when it's supposed to work. You still have not provided any counter-examples aside from the interaction with narrowing.

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.

I've been cheeky in the other parts of the message, this is just the reality: you have no standing to complain about the pushback if you push alternative proposals but do not bother to get familiar with other programming languages and the major modes' that use the current facilities.

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

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

But like he said, normally, you just don't. 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.

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.

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.

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.

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?



reply via email to

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