[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?