Re: font-lock-syntactic-keywords obsolet?

[Dmitry Gutov]

On 06/21/2016 05:40 PM, Alan Mackenzie wrote:

> > Does C++ mode in master support raw strings already? Is there a limit on
> > how far you look for the end of the raw string, and if yes, how much is it?
>
> Yes, no, and N/A, respectively.  Try out this raw string support,
> sometime.

I will.

> At the risk of reigniting arguments, the current mechanism pays no
> attention to the buffer text before a change.  So, if this is relevant
> to the bounds of the region wanting syntax-table props applied/deleted,
> the s-p-extend-r-f mechanism will need to be supplemented by a
> before-change function.  The sort of situation you'd need it is where a
> buffer change consists of deleting an escaped EOL.  If you only look at
> the buffer in a-c, you'll have no idea how far back the original C Macro
> extended, for example.

This makes a certain amount of sense, but I disagree with the 
conclusion: the fact that you *can* do this additional stuff in 
before-change-function, then save and use the resulting information 
later inside syntax-propertize-extend-region-functions, means the latter 
is general enough.

But if you were willing to change how CC Mode works further, maybe you 
won't need this. Instead, you need two things:

- A way to get back to a "safe" position. (syntax-ppss) provides this, 
as long as the only types of contexts one has to worry about are 
comments and strings (maybe different kinds), but with C/C++ you may 
have to first (goto-char (car (nth 9 (syntax-ppss)))) and then parse 
locally from that. Failing that, you could keep your own cache of safe 
positions, similar to syntax-ppss cache.

- Know how to syntax-propertize buffer contents going forward from a 
safe position. You must know this already because you can 
syntax-propertize a newly opened buffer.

So when the user edits something inside a macro, 
cc-mode-syntax-propertize, when called on that position, will go back 
and re-propertize the whole macro, along with all buffer contents 
between the safe position and here.

There's a certain overhead associated with this approach, but it's been 
working rather well in many cases, and it's conceptually simple. Maybe 
you should try that and see how big the overhead is.