On May 29, 2016, at 3:36 PM, Alan Mackenzie <
acm@muc.de> wrote:
Hi, Ivan.
I've now got a patch, which I'd be grateful if you could try out, both
to see if there are any bugs, and also to get your general impression.
I think there are one or two bugs left in the code, and it needs tidying
up quite a lot. So this won't be the final version.
Awesome. I’ll keep looking and let you know of any bugs I find.
char brackets [] = R"0x22[(foobar)0x22[";
Now, I’ve never actually seen such a construct in the wild, but it would be good to fix it regardless. The *Messages* buffer shows
File mode specification error: (invalid-regexp Unmatched [ or [^)
Error during redisplay: (jit-lock-function 1013) signaled (invalid-regexp "Unmatched [ or [^")
which seems to point to a missing regexp-quote, and indeed it thinks
char bar [] = R"YYY*(bar)YYY";
is a valid string literal.
Moreover, I was somehow able to get it into a bad state where changing the delimiters wouldn’t update fontification. I’ll see if I can come up with a recipe for how to reproduce it reliably.
The patch will work only on the savannah master branch - sorry, but it
depends on the fix to the "infrastructure" bug which I committed to
master only this morning (timezone +0200).
I'm also attaching a small test file which might interest you.
On Sat, May 28, 2016 at 02:40:45PM +0000, Alan Mackenzie wrote:
Thanks for the suggestion! I've actually had an almost working solution
myself for just over a week. Then I got confused with a bug in some CC
Mode "infrastructure" code. Such is life!
The way I am fontifying these is thus:
(i) For a correctly terminated raw string, everything between the ( and )
inclusive gets string face, everything else just the default face:
R"foo(bar)foo"
^^^^^
font-lock-string-face.
I was wondering how this would work. It’s a little weird that regular string delimiters are fontified with font-lock-string-face, but these aren’t. But I think I like this way better since it’s much easier to confuse these delimiters with the contents of the string than normal string delimiters.
(ii) For a construct with a raw string opener, not correctly terminated,
I am putting warning face on the entire raw string opener, leaving the
rest of the string with string face, e.g.:
R"baz(bar)foo"
^^^^^^
font-lock-warning-face
^^^^^^^^
font-lock-string-face
Of course, that is subject to change if it doesn't work very well.
CC Mode doesn't actually use syntax-ppss and syntax-propertize-function,
since they don't allow enough control. In particular, on a buffer
change, they erase all syntax-table text properties between point and end
of buffer which is wasteful; it is never necessary to erase these beyond
the next end of statement, and they are quite expensive to apply.
Anyhow, we should be able to have this implemented and the bug closed
pretty soon.
Thanks a bunch for your work on this.
-Ivan