Roslyn: C# auto-formatter always changes tabs to spaces around comments

[lorcanmooney]

class Program
{
    static void Main()
    {
        return;     /* Comment preceded by tabs */      // This one too
    // Type the closing brace here, and watch your precious tabs vanish...
}
// ...or type it here and, along with the vanishing tabs,
// see the third comment get indented by tabs AND spaces!

What happens to the third comment seems to vary by length of the content in the multi-line comment.
This happens on the Update 1 CTP (14.0.24606.01).

[CyrusNajmabadi]

Note: I think 'tabs vs spaces' is generally about what will be used for indentation. It's not about general whitespace between any constructs. For example, if you had: if<tab>(, then that would still get replaced with if<space>(.

[Pilchie]

I don't believe that _was_ the behavior in VS2013. You can certainly imagine using tabs to format something like a table of initializer elements (though we already leave those alone).

@lorcanmooney Can you explain the rationale for _wanting_ to keep tabs in those places?

[lorcanmooney]

@CyrusNajmabadi I don't entirely agree (after all, when "Keep tabs" is turned off, pressing the Tab button will insert spaces, _regardless_ of where your cursor is) but I see where you're coming from, so I've updated the issue to remove it from the equation.
@Pilchie There's some benefit to using tabs to keep end-of-line comments, since they're more tolerant of small edits to the preceding text and keep the comments vertically aligned (this is how I encountered the change). However, I actually don't think there's a huge argument for either one, and _this_ is the main issue I have with the new behaviour. It changes what's typed, for no particularly good reason, so it comes across as if the editor is fighting the user.
Of course, it's also possible I'm a little sensitive to these sort of changes after the other more serious tab-related issues.

[CyrusNajmabadi]

It changes what's typed, for no particularly good reason

Well... not exactly. The "good reason" is that it's formatting your code and it thinks that non-indentation whitespace should be spaces. Now, I agree that if that's not what you want, it's unhelpful. But for me it's very helpful (as I like to keep my code consistent with the standard formatting behavior). It sounds like we may need (if we don't have it already) a way to just say "do not format at all. Just indent". Then you could use tabs to your hearts content and we wouldn't touch it.

If we had such an option, then we wouldn't bother touching the tabs between your comments.

[lorcanmooney]

But for me it's very helpful (as I like to keep my code consistent with the standard formatting behavior).

I guess that's probably the root of the issue, and why I associated it with the "Keep tabs" setting. I use tabs, so for me, using tabs to align pieces of text is what _I_ consider consistent.

[lorcanmooney]

...do not format at all. Just indent...

Also just to be clear, that's not what I'm asking for. I _never_ want to see tab separated parameter lists, even if I happened to press tab! :-D

[CyrusNajmabadi]

Sure. In that case, I don't think you should be using the C# formatter at all. The C# formatter is fundamentally space oriented. Like with the example I provide, if<tab>( is just always going to be formatted to if( or if (. There's really no facility for actually using tabs for _formatting_ (while there is for _indentation_).

I never want to see tab separated parameter lists, even if I happened to press tab! :-D

This is the crux of the issue. You never want tabs preserved in some places (i.e. parameter lists). You always want them preserved elsewhere (i.e. between comments for example). In order to support this we'd have to provide options for _every single formatting behavior_ saying "use tabs for this" or "use spaces for this". That's an exceptional amount of complexity for a very narrow use case.

I think it would simply be more valuable to allow formatting (not indentation) to be turned off entirely. Then you can do whatever you want with spaces/tabs in your own code, and they'll be respected.

[lorcanmooney]

In order to support this we'd have to provide options for every single formatting behaviour...

I think that characterization is a little unfair. I reported a regression, or at least a change, from the VS2013 behaviour. All I considered was the restoration of this particular behavior. Now if that change was intentional, or turns out to be a bug that's not worth fixing, then so be it.

[CyrusNajmabadi]

I think it's intentional. We go and fix up the whitespace between our tokens/trivia. In some cases we explicitly don't touch things (i.e. in an array initializer) because there are so many different ways people do things. But I think normalizing how we space out comments is intentional.

[Pilchie]

Unfortunately, we're not going to have time to address this in 1.1, but I want to keep thinking about it.

[Pilchie]

Also reported at https://developercommunity.visualstudio.com/content/problem/43471/keep-tabs-issue-ide-replaces-tabs-with-spaces-c-ed.html

[Kruno313]

If I check "keep Tabs", I expect tabs to be retained ewerywhere I used them.
There is no option to control or disable identation of the comment itself, as we have it for any other type of text (after ',' or after ':' or before and after '(' and ')' ). So we can not disable that part of the formating separate.
It is clear a design flow and disturbs me all the time. At least in VS2008 it worked the right way.
To disable entire Code-Formating is not practicable. I wish to have it, but it should respond properly to already existent "keep Tabs" option.