Tab and indent size should be seperate settings as in previous VS versions by CoderBrien

Thank you very much for reverting this. We have around 10 million lines of code that runs or has run on old and new OSes going back to VAX/VMS and the only sensible choice for that is using a tab size of 8. Our indent size is 4.
Thank you for sparing us the pain of converting everything.

thanks for reverting this!!!

Thank you!!!

Hi everyone,

Thanks again for all of your feedback. We have reinstated "Tab Size" and "Indent Size" as two separate options for VS 2010 RTM (but *not* RC) and fixed the major known bugs I alluded to in previous comments, so I'm re-resolving this bug as Fixed. You should see the behavior of VS 2008 and other previous versions in the final release of Visual Studio 2010.

- Brittany

Neither of Brittany's suggested workarounds appear to work with RC1. So a feature I have relied on for over 15 years (and one that VS was one of the few editors I've used to implement properly) is no more. Arrrgh!

I use tab size 8, indent size 2, keep tabs. Well, I did. Repairing all of my code is going to be a pain.

This has been the most insightful comment I've read on Slashdot in a long time:
http://developers.slashdot.org/comments.pl?sid=1522790&cid=30886186

"No.

They solicited input from each other and in a blog post that generated a handful of responses. They did this to eliminate "a class of bugs" in the new editor that was triggered by setting the two numbers to different values. Which means they had a bunch of bugs (probably due to confusion between the two settings in the code) and someone had the brilliant idea that the bugs will go away if they just crippled the editor in such a way that the bugs will never be triggered. They solicited input, very quietly, and did it. This also means that the workaround they offer (writing a fucking extension, for fucking crying out loud - what is this, emacs?) will trigger all those bugs because they didn't fix them.

Idiots."

(no, I'm not the original posted)

I don't know how that got mistyped, but I meant tabstop = 8, indent = 4 of course. And yes, I do mean TWO MILLION lines of code.

Great, so now I'm being told that out of my 2 MILLION lines of code formatted with tab stop=4, indent=4 will never be properly displayed in Visual Studio again.

And I might add that the 9 "votes" are simply people that dont care, who this will not affect. So really you have 26 for "letting the user decide", and 0 against - they just dont give a damn.

The blog with the "feedback" that you are citing has only 8 comments, 1 of which says "give folk maximum felxibility to work the way they feel comfortable with." and the other one is from the author of the article saying "I assure you we won't be changing that option any time soon :-)"

So your total on that blog is 6 for restricting the user, 2 against

That's not very much feedback supporting your decision here, considering you've got 3 for restricting the user, 24 against here.

Therefore, so far the "let the user decide" camp is winning 26-9.

Personally, because of use with unix and VMS our coding standards are indent 4 tab 8 and this is critical. if one uses 4/4 then the code is not readable on a terminal emulator on unix or VMS - and we have to be able to do that for debugging and development - for those times we must do so on those paltforms. Sure in an ideal world one would never use VI - but we dont get to choose on a customer site. One cant just convert everythign to spaces - becase then its a royal pain to edit on the unix platform, then its the wrong format when it gets back to VS. I wish I had personally known about this 6 months ago - as I would have commented then - but asking Windows MVP's about a setting thats predominently for those who write and debug cross platform code - seems short sighted. it appear that the editor though re-writtten) still honors the settings if a project is upgraded - so its not as if the code was not implemented. whenones software is predominently server based - the world still does not see windows as the predominent server paltform, and c/c++ is used far more in server code than C# or vb.

I vote to change it back. This seems like we're taking a step backwards in functionality and simply makes things more complicated for people that do development in other editors/environments. IMHO we shouldn't make such a change that will impact so many people by soliciting feedback from such a small base. This will delay our adoption of the software and create additional headaches for my team and I by having to implement workarounds right out of the gate for something so basic.

I do however appreciate your time and responses Brittany. Any help you could offer in getting this corrected would be greatly appreciated.

Well that was a bad mistake.

Request for reopen - revert change:

I agree that tab settings don't matter much in the Visual Studio ecosystem, but any cross-(development-)platform code will certainly be affected.

Indent and Tab settings are often mandatory per style guidelines, it is not a personal choice.

The rationale for the change is to "eliminate a class of bugs that originated from setting them differently", which means the workaround posted will stop to function correctly sooner or later.

I understand the rationale, and if it stabilizes the build the better for me, as I I am - with my current line of work - NOT affected. However, I have worked in many environments that have separate settings - in most cases because TAB size needs to remain at 8 blanks for some of the tools involved.

This is a basic editor customisation. I like to customise this as many others. Please at least provide a plugin through codeplex to customise this.

Thanks again to everyone who has voiced an opinion on this issue. I unfortunately have to reiterate what I posted earlier: we cannot revert the UI for this before RTM. It's too late in the product cycle and too close to the VS 2010 ship date. Had the team heard this feedback a few months ago, the discussion about what to do for VS 2010 RTM could potentially have been reopened; again, we did phase in this change gradually and poll a wide variety of internal and external users to make sure all points of view could be considered before making a final decision. We'll be revisiting this issue for future versions and possibly for a VS 2010 service pack if/when one is to be released, but for RTM we're simply out of time.

Regarding Austin's suggestion to support per-project rather than global settings, I agree that this would be helpful to many users. That's something no version of Visual Studio has yet supported, and again we're well past the point of adding new functionality for VS 2010, but it's on our list of good ideas to consider for a future version.

Thanks again,
Brittany

Tabs have been 8 chars since the dawn of time, across different apps, and different OSes.
People quite often have house coding rules which mandate an indent size != 8.
So the ability to set tab size separate from indent size is crucial.

Please revert back to the previous UI.

In an ideal world, these settings would be per-project, rather than global to the editor.

Thanks,
Austin

As with the original parent, our shop also develops code that has to pass through a wide variety of environments and Tab=8 is the only thing that makes sense for that and we have been changing that in VS since VC6.    However indents at 4 is the shop style we have been using for twenty years and it is nonsense to force us to either change that or live with code that has garbled tabbing.

Hi Brien,

It's unfortunately not as simple as finding someone who wants a feature to be a certain way. Merging these two options into one eliminated a class of bugs that originated from setting them differently; we didn't consider changing this simply because we felt one fewer text box would constitute a significant improvement. In the absence of a critical mass of users who voiced negative feedback, we made the decision to update the options.

From a schedule perspective, we're quickly approaching the final release of VS 2010. UI is already in lockdown and we're unfortunately not planning to reverse this decision for this release. I would encourage anyone who would prefer VS return to two separate options to vote on this bug, as your feedback can certainly influence decisions about this issue in the future. For VS 2010, either of the two workarounds mentioned above (import settings from VS 2008 or use the posted extension code) should still allow you to set Tab Size and Indent Size however you'd like.

Thanks again,
Brittany

Wow, Here's you responding to someone who uses the same exact SANE settings that I need. So what other feedback were you looking for? How many people need to explain why these need to be distinct settings?

http://social.msdn.microsoft.com/Forums/en/vseditorprerelease/thread/288c5732-84cf-4847-901f-34fc7e2de669

Brittany,

The blog post that you reference is framed as an effort to "understand about how you use Visual Studio" in order to "improve it". I'm sure if your post was entitled "Hey, does anyone care if we combine these 2 settings?" you would have received quite a different response from the public.

Also, the one response to a commenter who correctly noted that this is "a can of worms" was:

VSEditor-
Daniel - You're right that the tabs vs. spaces debate can get pretty heated; I assure you we won't be changing that option any time soon :-) Tabs vs. spaces is helpful information to know when considering developers' preferences for tab/indent size, though, which is why I ask.

All said, I don't see at all how doing this _improves_ VS. Quite the contrary. Clearly if the settings can be changed with the code you attached, the core support is there and this is simply a UI issue.

Additionally, the graying out of the settings in VS2010B1 was interpreted by me to mean "it doesn't currently work". There were other things in the beta1 that were placeholders and didn't work. I wouldn't go through the trouble to open an issue for a grayed out setting I need. I would wait for the release and assume it is implemented properly.

In any case, what you've essentially done is to make files with embedded TAB characters unusable within VS since there is no control over how they are interpreted without changing the indentation size. So for all the users that exist in a vacuum having one less text box in the settings dialog should make them very happy. For me, you've just added additional friction.

And if you were really lacking in opinions on this topic, a simple web search may have led you here:

http://www.codinghorror.com/blog/archives/001254.html

Hi Brien,

Thanks for your quick response. This is a somewhat long post for Connect, but I hope you'll find the information valuable.

Regarding user feedback on the decision to merge these two options, we asked a wide variety of people and phased in the changes gradually. We blogged publicly about the potential change on the VS Editor blog (admittedly not the most widely-read VS blog, but readership was significant enough to generate discussion): http://blogs.msdn.com/vseditor/archive/2009/03/19/how-do-you-use-tab-size-and-indent-size.aspx. We solicited feedback from members of Microsoft's MVP program, who spend a lot of time in Visual Studio, and from many internal teams and developers who use Visual Studio. We also phased in the change gradually: for Beta 1, Indent Size was disabled/grayed out and always set to the same value as tab size. In the absence of negative customer feedback on this, we merged the Tab Size and Indent Size options into a single “Tab and indent size” option for Beta 2.

There are a couple of workarounds for users who would like Tab Size and Indent Size to remain separate settings with unequal values. The simplest is to set your desired tab size and indent size in VS 2008, export your settings, and import them into VS 2010. The VS 2010 editor will respect your unequal settings, though you will still see a single option in the Tools->Options UI.

The second workaround is to use an editor extension to force different values for Tab Size and Indent Size. I wrote a quick extension for this and have confirmed that it works against VS 2010 Beta 2. Here's the code - this version sets Tab Size = 8 and Indent Size = 4 for C#, but it can be modified to set any values for any language.

using System;
using System.ComponentModel.Composition;
using System.Runtime.InteropServices;
using EnvDTE;
using Microsoft.VisualStudio.Editor;
using Microsoft.VisualStudio.Shell;
using Microsoft.VisualStudio.Text.Editor;
using Microsoft.VisualStudio.TextManager.Interop;
using Microsoft.VisualStudio.Utilities;
using OleInterop = Microsoft.VisualStudio.OLE.Interop;

namespace TabAndIndentSize
{
    [Export(typeof(IVsTextViewCreationListener))]
    [ContentType("text")]
    [TextViewRole(PredefinedTextViewRoles.Document)]

    internal sealed class AdornmentFactory : IVsTextViewCreationListener
    {
        public void VsTextViewCreated(IVsTextView textView)
        {
            new TabIndentSetter(textView);
        }

        private class TabIndentSetter
        {
            IVsTextView _view;
            private const int TabSize = 8;
            private const int IndentSize = 4;

            public TabIndentSetter(IVsTextView view)
            {
                _view = view;

                #region Get a DTE object
                DTE vs = null;
                // Grab the ObjectWithSite to help find the Service Provider
                OleInterop.IObjectWithSite objectWithSite = (OleInterop.IObjectWithSite)view;
                if (objectWithSite != null)
                {
                    Guid serviceProviderGuid = typeof(OleInterop.IServiceProvider).GUID;
                    IntPtr ppServiceProvider = IntPtr.Zero;

                    // Find the service provider by Guid and obtain the IntPtr for it.
                    objectWithSite.GetSite(ref serviceProviderGuid, out ppServiceProvider);

                    if (ppServiceProvider != IntPtr.Zero)
                    {
                        // Get a ServiceProvider object
                        OleInterop.IServiceProvider oleInteropServiceProvider = (OleInterop.IServiceProvider)Marshal.GetObjectForIUnknown(ppServiceProvider);

                        using (ServiceProvider serviceProvider = new ServiceProvider(oleInteropServiceProvider))
                        {
                            if (serviceProvider != null)
                            {
                                // Use the ServiceProvider to get the DTE.
                                vs = serviceProvider.GetService(typeof(DTE)) as DTE;
                            }
                        }
                    }
                }
                #endregion

                Properties props = vs.get_Properties("TextEditor", "CSharp");
                props.Item("TabSize").Value = TabIndentSetter.TabSize;
                props.Item("IndentSize").Value = TabIndentSetter.IndentSize;
            }
        }
    }
}

Could you let me know whether one of the workarounds is acceptable for you and your team? Please feel free to post again here if you have further questions or comments; I'm happy to help however I can.

Thanks again for your feedback,
Brittany

Brittany,

Can you please provide a link to any blog postings made about this? I follow many visual studio blogs and have never seen this mentioned.

Yes, I would definitely like to see the editor extension example, as not having these settings available is going to cause my team a lot of problems.

Thanks,
Brien

Hi Brien,

Thank you for logging this issue. Before making this change we solicited feedback on the decision to combine Tab Size and Indent Size from a wide variety of sources, including public blog posts and forum threads, and found that the vast majority of user feedback was in favor of combining the two. If it's seriously impacting your code to have Tab Size always equal Indent Size, it is possible to write a short editor extension to override the Tools->Options dialog and set the two options separately. If that's something you'd be interested in, please let me know and I'll see about posting sample code for how to do this.

I'm resolving this issue as By Design because we intentionally combined these options for VS 2010, but please feel free to post again here if you have any further questions or comments and we'll be happy to help.

Thanks for trying Visual Studio 2010 Beta 2 and sending your feedback!

Brittany Behrens
Program Manager, VS Platform - Editor
http://blogs.msdn.com/visualstudio

Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you

Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)