Roslyn: VS2017express C#, tabs replaced with spaces

[vsfeedback]

Hello,

under the following circumstances, VS2017express replaces tabs with spaces even though I deactivated that feature in the options:

• I am working on a C# file
• I am pasting a tab from my clipboard into a line of code, but not at the end, e.g. "int i = 0; // init i". If I want more space between the command and the comment and I use my tab key, then tabs get inserted properly, but if I put a tab into my clipboard and insert it with Ctrl-V, then ALL tabs get replaced with spaces.

This problem does not occur in C++ files of the same solution, even though I set the tab configuration identical for all languages.

Cheers
Peter

_This issue has been moved from https://developercommunity.visualstudio.com/content/problem/154651/vs2017express-c-tabs-replaced-with-spaces.html
VSTS ticketId: 528589_
_These are the original issue comments:_

Peter Meier on ‎11‎/‎23‎/‎2017, 02:27 AM (41 days ago):

Also I just found out that if I hit the auto format keys (Ctrl-K, Ctrl-D), all the tabs I inserted between the command and the comment are replaced with spaces again. I searched through Tools/Options/Text Editor/C#/Code Style/Formatting, but I found no way to change this annoying behavior. I don't understand why C# won't let me align my comments the way I want them to be when it's no problem for C++.

Jinu Joseph [MSFT] on ‎12‎/‎20‎/‎2017, 02:48 AM (14 days ago):

We appreciate you taking the time to report this problem. We are currently prioritizing problems that are impacting a broad set of our customers, so we may not be able to investigate this one immediately. We know this problem is important to you, so we will continue to monitor it.

_These are the original issue solutions:_
(no solutions)

[jcoutch]

I'm having a similar problem with Visual Studio 2017 Professional (15.7.0.) I have my indentation style set using .editorconfig:

[*.cs]
indent_style = tab
indent_size = tab
tab_width = 4

If I add a newline to a C# file, tabs are inserted as expected. But, if I format the document using Ctrl+K Ctrl+D, any tabs in the file are replaced with spaces.

If I use ReSharper to format my document, all indentation is converted to tabs as expected.

[FlorianHaupt]

Would be nice to get this fixed, would save much time.

[elliott-beach]

I was thinking of submitting a repro, but the OP hits the nail on the head:

just found out that if I hit the auto format keys (Ctrl-K, Ctrl-D), all the tabs I inserted between the command and the comment are replaced with spaces again. I searched through Tools/Options/Text Editor/C#/Code Style/Formatting, but I found no way to change this annoying behavior.

This creates big whitespace changes after formatting the document as we use tabs at work. Please fix this.

[sharwell]

📝 The issue here is hard tabs contained within a line of code, i.e. tabs not used for indentation.

[kendrahavens]

Design meeting notes:
In the past we've had conflicting requests on the behavior for tabs within a line of code so we need to add an option for this behavior.

My proposal:

• add editorconfig setting that enforces tabs within a line of code. tab_within_line
• add new toggle in Tools > Options > C# > Tabs: Enforce tabs within lines.
  
  
  
  • It could also go under Tools > Options > C# > Code Style > Formatting > Spacing if that is the preferred place to keep editorconfig settings.
  
  

@heejaechang @sharwell

[FlorianHaupt]

@kendrahavens
Nice proposal to add an extra option.

Design meeting notes:
In the past we've had conflicting requests on the behavior for tabs within a line of code so we need to add an option for this behavior.

Are there really users that like to keep tabs only on specific parts, like indent?

As the current option does reflect what it should do, to "keep tabs" and do not replace them with spaces - This is the behavior as I know it from previous versions and as it is within the C++ text editor - I would prefer an new option that says "keep tabs only for indent" for this new behavior. One saying "Enforce tabs within lines" would still confuse and let me wonder why I have to check that extra option in situations I already selected "Keep tabs".

[sharwell]

Are there really users that like to keep tabs only on specific parts, like indent?

Yes, it's actually a primary request for users who indent with tabs.

The name of the new option has not been decided, but it would have two options:

1. Allow tabs whenever Tab is used (matches the behavior prior to Visual Studio 2015)
2. Use tabs for indentation, but not for alignment

In most cases, the second option behaves as you see today. However, the behavior would change in cases where hanging indentation is used for aligning code with code on a previous line. For example:

void Method()
{
→   var·data·=·from·value·in·new[]·{·1,·2·}
→   ···········select value;
}

[sharwell]

The preliminary design discussion is now complete. We will review the final user experience once it is ready.

[levicki]

The issue here is hard tabs contained within a line of code, i.e. tabs not used for indentation.

I keep hearing people referring to tabs as hard when it's actually the other way around -- tabs are soft (as in you can replace them with any number of spaces on display),, and spaces are hard (as in hard-coded number in the file itself which you can't reformat so easily on display).

That said, I would really prefer if Tab key did what it says on the tin -- inserted a Tab character into the editor. Currently in Visual Studio 16.5.4 that doesn't seem to be the case even though I have configured everything to have Tabs instead of spaces.

I'd like to voice my displeasure towards two trends going on in Visual Studio editor since VS 2015:

1. Editor trying to be "smart" and disregarding user input more and more (i.e. I enter Tab and it enters spaces even though it's clearly configured to use Tabs)
2. Premature code analysis and error checking (i.e. telling you your code is broken and offering to "fix" it before you ever get a chance to complete it)

Those additions waste enormous amounts of developer time and effort on fighting them when they are wrong (and sadly they can be wrong a lot). The least you could do is offer an option to disable both behaviors globally.

Finally, I'd appreciate if there was some workaround for this spaces instead of tabs issue, it's driving me nuts.

[Edgs]

This is still a problem. The older versions of editors never used to behave like this. Other editors don't behave like this. Even Notepad doesn't behave like this.

I'll explain simply:
With the option to KEEP TABS selected in the Editor settings, TABs typed within code (so end of line comments line up, for example.) are later changed into spaces by Visual Studio. When copying & pasting a line, for example.
I NEVER want this to happen. That's why I select the option to KEEP TABS.
If I type a TAB in my code, I NEVER want it changed it to spaces. It's really that simple.

Why is this not fixed after 2+ years?
This is not an enhancement request, but simply a request that the editor behave as editors have always behaved since the dawn of computing. At some point, someone in Microsoft decided to 'muck' around with users typed code and change it, when not one user asked for that to happen.

Are there really users that like to keep tabs only on specific parts, like indent?
Yes, it's actually a primary request for users who indent with tabs.
That's simply not true. Show us ONE request from ANYONE who asked for their TABs to be changed to spaces within their code when using the option KEEP TABS.

Also worth noting that this still happens when the 'Use Adaptive Formatting' option is turned off. So it is impossible to prevent this from happening.

[sharwell]

Why is this not fixed after 2+ years?

There is no one consensus on the definition of correct behavior. The overwhelming majority of users are happy with the current implementation of tabs/spaces handling. Accounting for the remaining ones (in particular, https://github.com/dotnet/roslyn/issues/24031#issuecomment-444067640 and "always use tabs") without breaking the experience for users who are happy with the current behavior is a particularly challenging exercise that requires both design and implementation work.

I'm not sure this will move up on the internal priority list in the near future, but if an external user wanted to spend the time to define and implement the full experience we would be happy to review it. See #23394 for a great example of a feature which shipped because a contributor went through this process. 😄