@asipe: actually, very few other editors offer coloring based on symbol properties, like scope and whether it is defined or not. I have no doubts that some may be more performant or require less tweaking. If, like ReSharper, we knew that all we were going to deal with was .NET, then we could pick different defaults. However, the defaults needed for .NET would not be optimum for the typical C/C++ project. ReSharper also only supports C# and VB.NET (I believe) and only has to run on one platform: Windows. I certainly think we can improve our Symbol Coloring implementation, but you make it sound like we botched a simple feature that everyone else provides, which is overstating the issue.
I can agree with your points about resharper and only dealing with c# and windows, etc... But that doesn't really help with the problem, does it? Basically you are saying that they can provide better performance because they are serving a narrow market. OK, and this means what? Heck, I'm not even focused on the latest version, I've moved back to the previous version and still have complaints.
The fundamental problem is that VSE is so much slower that over the last 2 months I have stopped using it for any C# work. The other tool combo is just so much faster and gives me 99% of the features that I need. Sure, I can make VSE faster by turning off all its features but then what is the point?
The problems that VSE has with C# are fairly well documented in other threads but to summarize:
* tagging problems (even worse with symbol coloring)
* slow response time when jumping between references
* in ability to tag different frameworks for different projects
* slow slow slow integration with msdn help and again the inability to configure this on a per project basis for different frameworks
* constant manual retagging
* core features like surround and formatting don't work reliably, not to mention weird behavior when handling anonymous methods, delegates, templates, linq (format on paste, comment/uncomment, etc...)
* the inability of vse to handle multiple embedded languages inside files (aspx/js/embedded c#/etc...)
* poor xml performance overall
* always behind the features of the core frameworks
I understand that none of these are simple issues and I'm not saying they are simple fixes, but they are problems that the alternatives do not have.
Interestingly enough I can point to many of the same problems (and even more) in the ruby language support. That said, I pretty much stopped bringing these issues to the forums after hearing that ruby (as a language/spec) is moving far to fast for VSE to keep up (sigh). This coupled with some other recent support issues is a trend that I find disturbing.
I don't write an editor for a living. I don't want to have to spend time optimizing my editor for basic language support. I want to turn on my editor and have the features it says it supports in the languages it supports work with reasonable size projects in a speedy manner. Is that odd?
-andy