Hi,
I checked with the general vim mailing list to see if there was something
I've missed, before hitting vim-dev with this, and no one's said anything
about it, so I don't think there's a known quick fix for this. I have
reached out to an author of a vim script that fixes syntax highlighting
with curly braces in certain situations in c++11, and adds the constexpr
keyword, but I'm not sure if he will work on this, or if it's possible for
him to with syntax files. Either way, I figured it should be in vim itself
going forward.
As you may already know, c++11 supports raw string literals. I'm sure they
supported it earlier, but gcc "experimental" source build 4.7.0 allows you
to use:
string str = R"(this"is some text)";
Instead of having to use:
string str = "this\"is some text";
In the right situation, this saves many escapes, crossed eyes, and
headaches.
Unfortunately, there's something else that might make this more complicated
to support. The general case allows any of these to work:
R"(String literal \t (Without a tab))"
u8R"(Raw UTF-8 string literal \n (without a newline))"
uR"(Raw UTF-16 string literal \\ (with two backslashes))"
UR"(Raw UTF-32 string literal \u2620 (without a code point))"
The raw text delimiter is often going to be "( and )", but it can be
anything, so )" can also be in a raw string.
R"asdfasdf(This will work)" just fine as one string)asdfasdf" // turns
into: This will work)" just fine as one string
and
R"!("operator\(\)"|"operator->")!" turns into "operator\(\)"|"operator->"
I'd love for vim to support this, whether that means a new syntax file, or
even if I need to run a developmental source build. Even though it saves a
lot of escaping characters, vim (understandably) gets very confused.
Thanks!
Mike
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
