Often when going through code, usually when debugging, I'd click on a method and drill through it to find some higher level spot where it's called, and go back down in the hierarchy again.

The preview tab makes that ****** since it only opens the last file you drill through, so I can't really go back to the previous file that was opened in the preview tab, which forces me to find that spot manually once again.

Now although I hate XCode with a vengeance, I did notice, ironically after going back to visual studio, that it does one thing right;
When you drill down through your code, you can go back and forth to the last positions you went through with "jump to definition", even in the same file. This allows you to go back where you were before and works really well.

XCode actually doesn't do this perfectly since the way tabs are used in XCode is rather poor and annoying (it opens everything in the same tab). But if this back & forth mechanic would work over multiple tabs it would be ideal in my humble opinion.

Often when putting together a new color scheme you will set most colors straight away, but later will find something that for whatever reason is a color which has very poor contrast with the background or text.

At the moment to fix this you have to trawl through the hundreds of color options until you find one that might be the issue. You then change it and see if you were correct at guessing the correct rule. Often I have to repeat this process many times.

I propose a menu option which tells you what color rules are effecting whatever is under the mouse, but I'd be happy with any way that made it easy to figure it out.

Adding references is quite a pain. There are just too many assemblies required to be added just to get the job done these days.

If the code editor detects that it doesn't know a type of namespace, it could easily do a background search (At least for assemblies in the GAC, those in the private/public assemblies folders and other paths that may be added. It can then suggest one or more assemblies, providing the path, version and other information that will be helpful in deciding when one(s) need to be added.

This would be a really big boon as well as a time saver.

While I realize that there have been other suggestions to fix the problem that is that there are a gargantuan number of items in the "Display items" listbox, and the window is not resizable, and the items are only grouped at one level ("Show settings for"), I would like to propose a solution to the madness.

Add a component-aware eyedropper-like tool, something like Spy++'s "Find Window" tool with the target button, so that the user can just move the Options window aside, click the "eyedropper"-ish button to start the selection process, and just click on the component to be selected in the "Display items" list. The component could be a keyword in the text editor or even something in one of the other windows. If there are multiple potential hits, a little context menu could appear to ask the user to select which item to select.

I realize that this might be difficult to implement, but there could possibly be more payoff even than the Fonts and Colors dialog, perhaps something along the lines of the scope of Spy++ but for WPF/managed apps.

There are some code blocks we need frequently when we do coding. My suggestion is to provide those code blocks in interface like tools in tool box, then developer can easily drag and drop that code block and start their coding inside the block. This will save the time and very conveninet.

Example : Let me take if-else statement as example,

if()
{
}
else()
{
}

When if-else block dragged and dropped then this code should be auto generated with proper indentation. Likewise we can apply this method to all frequently used codes(for, while, switch, array, exceptions, etc). This will also help to keep well indentation of a code.