[slurgfest]

Parsing C++ isn't required if all you are doing is syntax coloring.

vim has a fully configurable syntax highlighting system; its behavior is not hard-coded. So if you have a problem with how C++ is highlighted then you don't need to petition for the developers to patch or rewrite vim for you.

You can tweak the related configuration. And it's true that it's really not that hard to make your own new configuration to do this. Because you aren't compiling the code, you are only highlighting it according to your own tastes.

[Ralith]

Any syntax highlighting scheme which does not leverage a language parser is woefully limited. If you're satisfied with a scattering of heuristics, great; you'll find satisfaction in a much wider set of tools. Myself, I want syntax highlighting that doesn't break as soon as I do something unusual, and which is capable of more than identifying keywords.

Given that vim is open source, I'm not sure why you think hard-coded syntax highlighting would be impossible for me to modify.

[slurgfest]

Mind the context: the guy said there needed to be a "new VI" to have "better" syntax highlighting (whatever specifically he meant by that). You broke in to emphasize how tough it is to parse C++, which is true, but not entirely relevant; the person you replied to was simply pointing out that it's easy to reconfigure vim's syntax highlighting to almost any requirement. Which is true, by the way.

It appears that you are preoccupied with hard-coded construction of ASTs for some dialect of C++ inside your editor. I never suggested it could not be done. But, this is a different issue.

However, I really don't think many people need that when the facilities for configuring syntax highlighting are so good. The existing system has allowed vim to support a crazy number of languages and have fresh support for languages quite quickly after they start to be used.

If you like vim, and you want something SPECIFIC to be fixed about its C++ highlighting (not just a general complaint that you feel it is 'woefully limited' because it isn't based on hardcoded static analysis for C++) ... then don't waste time on doubt. Just try it. Make your own highlighting script and see if it works to a usable level. If it does not, then you know, and not just because of some a priori principle that syntax highlighting is useless unless it is based on an AST generated by your compiler toolchain or something.

If you really did have any practical reason to believe that the existing syntax highlighting facility was totally unsuitable for more than a handful of people... maybe it would be interesting to have some way of plugging in external modules of some kind to provide ASTs for specific languages. (Because I think the idea of making my text editor totally coupled to a specific hard-coded implementation of a parser for a particular language sucks really bad; but if you don't think that, then maybe you just want to buy a C++ IDE and be done with it)

[Ralith]

What makes you think I want anything hard-coded?