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, #24031 (comment) 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. 😄

[levicki]

@sharwell

There is no one consensus on the definition of correct behavior.

How about you take the same approach as Git does for line endings?

1. Replace TABs with spaces on reformat
2. Replace spaces with TABs on reformat
3. Leave both as entered on reformat

Shouldn't the above satisfy everyone involved?

Come on people, this is not rocket science, it's a text editor for $(Deity)'s sake!

[CyrusNajmabadi]

So far you have not addressed any of my points, instead you keep spouting some weird mix of anti-tab religious zealotry and corporate PR talk.

If i've missed any points, i apologize. There's a lot being discussed here, and i likely missed it. Feel free to point it out once this is unlocked and i'll respond as best as i can.

because something could break while at the same time you are totally disregarding that it has already been broken for us, hence the bug reports.

i'm not disregarding this. I'm just providing some insight that sometimes it's better to just stick with a regression versus introducing multiple regressions at multiple points in time. i definitely commiserate with the initial regression being unpleasant. However, with a rewrite the size of roslyn and the entire formatting engine being rewritten from the ground up it was unfortunately the case that this did happen. However, now that we have the current system, i would be loathe to potentially have this same thing happen again.

I totally get that that can be frustrating. A group of people (that you are not a part of) is having their needs met, while yours are not. However, this really is a space where potential changes risk very bad outcomes for many groups. As i mentioned in #24031 (comment), this code is the most complex in the entire codebase for me. Changes to it are both non-trivial and carry a large amount of risk. Just a few days ago i discovered something new and unexpected about it for me, and i had to completely give up on a refactoring here because there was a part of this whose behavior was too subtle and complex to fully understand and i had to timebox myself out of it.

--

Again, I'm happy to help clarify any of my statements, or address any points i may have missed. My hope was to try to provide some clarity on the challenges here as this isn't really a case of: "oh, this is just a bug with a trivial solution" but rather more like "this is a potential mine-field that we have to be very careful of".

Also, as per #24031 (comment), i would be happy to continue this discussion in realtime on discord or gitter. It might be more conducive than here as we can cover a lot more stuff, and we can make sure any particular questions/concerns you have are responded to. If you are interested, LMK and i'm happy to meet up with you at practically any time. thanks!

[jmarolf]

I can certainly understand the frustration of Always keep TABs not doing what it says on the tin! I truly do want to fix this as we have under-served tabs users in the past and want to ensure it is just a viable and useful as spaces.

Let's talk potential solutions (setting aside for a moment the engineering cost) and see if we can agree on which one would be most helpful. Once we agree on a design, we can evaluate the engineering difficulty of it.

Tabs only mode

Simplest solution would be to have an option that means "if this option is on Tabs are never allowed to be converted to spaces by the formatter". I will tentatively call this Tabs only mode (since sadly "Always" is taken). I think this will operate like folks want but there is a corner case that has been called out that we need to consider which is what if we can't perfectly align things with just tabs?. So, if you set your tabs to some indenting (like say "4") we would try to get you as close as we can based on those settings with the understanding that we could be off by one or more. This would be an example of a worst-case scenario where we could choose to either be off by one or three when tabs have an indent size of 4.

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

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

I think intuitively we would say "We should be off by as little as possible". So, for worst case scenarios like the ones above we would choose option 2 over option 1. The question for this mode is can the developer ever actually get into a good state when things are not misaligned in this worst-case? The answer is probably not in this mode. Say I add an additional space in front of from:

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

The formatting engine will just take it away again as we already have a preference that keeps the spacing here to just one space. You could use spaces at the beginning of the line to align things and they would be left alone:

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

But that is dangerously close to mixing tabs and spaces which is the very thing we don't want to do. I think like it's not obvious to me what would be most excellent here. But I am just one guy what do I know? Maybe we try a vote?

• React with 🚀 for Tabs only mode, stop indenting, never overshoot

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

• React with 🎉 for Tabs only mode, choose the smallest number to be off by on alignment

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

Tabs preferred mode

An alternative would be "Use spaces as little as possible" named something like Tabs preferred mode. In this mode we would use tabs to re-align things and only use spaces iff there was no other means to get things to line up.

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

• React with 👍 for Tabs preferred mode

[levicki]

@sharwell

I apologize for being rude, but ever since Visual Studio 2015 I am sick of Visual Studio messing with my keyboard input and not respecting my configuration choices (and in some situations not even giving me any choice).

I understand that the problems with mixed tabs and spaces such as this very contrived example:

void function()
{
	LongClassName	c;					// tabs here
	HRESULT		hr = E_FAIL;

	if ((value ==  8) &&					// NOTE: Don't mess with comment alignment either
	    (  age == 21) &&					//       or someone will be really annoyed
	    ((flags & DONT_MESS_WITH_TABS) ||			
	     (flags & DONT_MESS_WITH_SPACES_EITHER))
	   ) {
		// TOOD: figure out how to handle this...
		abc.Value		= 3;			// and here
		abc.AnotherValue	= "MaybeNotTouchThis";
	}
	
	EvenLongerClassName e = new EvenLongerClassName();	// but not here
}

Are really complex to solve, but perhaps it would be prudent not to mess with indentation when mix of tabs and spaces is detected at line start? The rest of the line could be formatted according to the rules, leaving anything past the expression end as-is to avoid messing up comment alignment.

I understand that perfection will never be possible, but at least having an option to disable auto-conversion of tabs to spaces would be a start.

@jmarolf Thanks for starting the discussion about potential solutions.

Maybe we are approaching the problem from the wrong angle? Maybe we should instead define rules such as:

• Always use tabs for line indentation, comment alignment.
• Use tabs for variable declaration alignment unless they are in the middle of the code.
• Always use tabs for right aligning before assignment operator.
• Always align if sub-expressions on their opening paren.
• Always align left and right side in if comparisons on the operator inside paren, pad left or right side as necessary.

If I am not mistaken the rules such as those would produce the results as in the above contrived example. Again, I understand that it might not be possible to code such rules, but at least it should be possible for me to format the code like that without having to fight with the editor for every character I type.

[jmarolf]

@levicki thanks for this.

void·function()
{
→   LongClassName→   c;→   →   →   →  	//·tabs·here
→   HRESULT→   hr = E_FAIL;

→   if·((value·==··8)·&&→   →   →   →   →   //·NOTE:·Don't·mess·with·comment·alignment·either
→   ····(··age·==·21)·&&→   →   →   →   →   //·······or·someone·will·be·really·annoyed
→   ····((flags·&·DONT_MESS_WITH_TABS)·||			
→   ·····(flags·&·DONT_MESS_WITH_SPACES_EITHER))
→   ····)·{
→   →   // TOOD: figure out how to handle this...
→   →   abc.Value→   →   = 3;→   →   →   //·and here
→   →   abc.AnotherValue→   =·"MaybeNotTouchThis";
→   }
→   	
→   EvenLongerClassName·e·=·new·EvenLongerClassName();→   //·but·not·here
}

In the sections where we are using tabs to align comments. If we pressed enter a the ⌶ location what would you expect the formatter to do ideally?

→   ····(··age·==·21)·&&→   →   →⌶   →   →   //·······or·someone·will·be·really·annoyed

[Edgs]

In the sections where we are using tabs to align comments. If we pressed enter a the ⌶ location what would you expect the formatter to do ideally?

THE problem currently is that if you press enter on that line, or a line next to it, and a code or comment alignment takes place, all those tabs before the comment are replaced by spaces. Every time, no matter what TAB options are selected.
I don't think there's anything wrong with the 'alignment help' as it is, except that it ONLY uses spaces, and never tabs, as reqested by the user.

Please fix this.

[levicki]

@jmarolf You are welcome.

In the sections where we are using tabs to align comments. If we pressed enter a the ⌶ location what would you expect the formatter to do ideally?

Is there any particular reason why I would want to press Enter in the middle of those tabs? If I wanted to move that comment to the next line I would probably press Enter right after last non-whitespace character, not in the middle of the whitespace. That aside, I would expect it to indent the comment with tabs from the start of line, and if it cannot decide whether to also add spaces to align the comment to the same column as the previous line then just leave the caret before the first non-whitespace character so I can do manually whatever I want. If you intentionally wanted to split the line so that there are two tabs stuck to the coment going to the next line then I really don't know the answer, because I'd never do that unless: - There was no auto-indent functionality in the editor (think Notepad) - The previous line was indented with exactly two tabs. Even then, such an action would still leave me having to clean up the remaining trailing whitespace (i.e. the other two tabs) on the previous line, so that would make me doing it in such a way even less likely. As it was stated before, we don't need perfect solution. Hovewer, I am afraid that we have gone way too far in our attempts to enable software to predict and adapt to human behavior -- to the point of making the software behave as unpredictable and unreliable as humans themselves.

[sharwell]

Is there any particular reason why I would want to press Enter in the middle of those tabs?

If I wanted to move that comment to the next line I would probably press Enter right after last non-whitespace character, not in the middle of the whitespace.

In most cases, pressing Enter in the middle of whitespace already behaves the same as pressing enter at the end of that same whitespace. This feature is frequently used.

That aside, I would expect it to indent the comment with tabs from the start of line, and if it cannot decide whether to also add spaces to align the comment to the same column as the previous line then just leave the caret before the first non-whitespace character so I can do manually whatever I want.

Can you show this using the → and · characters?

[levicki]

@sharwell @jmarolf

In most cases, pressing Enter in the middle of whitespace already behaves the same as pressing enter at the end of that same whitespace. This feature is frequently used.

Funny, I never press Enter at the end of whtespace, but at the beginning.

Can you show this using the → and · characters?

I can try, in both examples below I assume pressing Enter at the beginning of whitespace.

Version 1 (VS editor cannot figure out whether I also want spaces or not after initial tab alignment)

→   if·((value·==··8)·&&
→   //·NOTE:·Don't·mess·with·comment·alignment·either
   ^- cursor here after pressing Enter so I can align further manually if I want
→   ····(··age·==·21)·&&→   →   →   →   →   //·······or·someone·will·be·really·annoyed

Version 2 (VS editor has gained awareness and is becoming Skynet by rewriting its own code as we speak)

→   if·((value·==··8)·&&
→   ....//·NOTE:·Don't·mess·with·comment·alignment·either
→   ····(··age·==·21)·&&→   →   →   →   →   //·······or·someone·will·be·really·annoyed

However, given that the code above was a rather contrived example (and I am pretty sure most of us would prefer the comment to stay where it is anyway, making this comment alignment discussion even more contrived), that still focuses on minor style details while not addressing the key complaint most of us tab users here have.

When I type this:

I don't want it being changed to this when I type ; at the end of line (or when such line is pasted):

Yes I know I can disable auto-format on ; and on paste, but I want other formatting to happen. If you at least fixed that, you would have much less complaints from tab users.

Finally, I'd also like to point out how much everything is geared towards people using spaces.

When you create a new C# library (.Net Framework) project in VS 16.9.1, initial code looks like this:

So, the template not only assumes I will be using spaces, but also that I will be using 4 spaces instead of 8 for example. Same goes for all other code templates, and that's why I keep saying that spaces are hard (as in hard-coded) and tabs are soft, not the other way around.

This one is trivial to fix by manually editing spaces to tabs, but there are other templates with more boiler-plate code which are not (C++ Windows DLL or Desktop Application projects for example).

If you wrote all those templates using tabs, then you could just replace all tabs on template instantiation with the amount of spaces the user has actually configured for alignment in the editor, or just leave them be for everyone else who uses tabs.

[Edgs]

Personally, I would be happy for no comment alignment to take place at all.
Code statement alignment is generally predicatable, and is mostly determined in the user options. The Editor can make reasonable assumptions about indentation if it is formatting code.
Comment alignment is completely arbitrary - for example I sometimes like to indent my comments, like pseudo-code, or sometimes have them all vertically aligned. The only thing the Editor can do with this is move it somewhere I don't want, or just leave it alone.

For example, currently I can copy and paste a block of code, and the Editor will keep the same predictable alignment for the code, but the comments will be moved in an attempt to align them with nearby comments. I don't want this to happen. The Editor is just guessing in this case, and the behaviour is unpredictable.
It's all made worse by the Editor only using spaces, so I have to go back & find & remove those to realign the comments as I see fit. In 9 times out of 10 it just creates more typing.

[levicki]

@jmarolf @sharwell

Here is another example of the undesired behavior I detailed with screenshots in my previious comment above:

Note that in my root Visual Studio Projects folder I have an .editorconfig file which contains, among other things:

root = true
...
dotnet_diagnostic.IDE0055.severity = none

However, it seems that IDE0055 configuration is being entirely ignored, and clicking on any of the Suppress or Configure issues sub-options for it has literally no observable effect (no GUI feedback, no file changes / creations, nothing).

[sharwell]

However, it seems that IDE0055 configuration is being entirely ignored

Something is overriding this value (most likely a .editorconfig file between that location and the location of the file also contains root = true, which prevents further inheritance).

[levicki]

Something is overriding this value (most likely a .editorconfig file between that location and the location of the file also contains root = true, which prevents further inheritance).

There is no such file between.

[sharwell]

Can you file a separate issue for that? Disabling a diagnostic is expected to disable a diagnostic. 😄

[levicki]

Can you file a separate issue for that? Disabling a diagnostic is expected to disable a diagnostic. 😄

There is already an issue for IDE0055 about it fighting vertical alignment (i.e. replacing tabs with spaces as I showed above). It's open for God knows for how long just like this one. I am not even going to mention the one I reported in .Net Environmet namespace two years ago.

Do you honestly believe that opening another issue will help? At this point I am discouraged to report more because nothing ever seems to get fixed (usually because "it's complicated").

[sharwell]

There is already an issue for IDE0055 about it fighting vertical alignment ... Do you honestly believe that opening another issue will help?

Yes, you're describing a bug related to a feature much bigger than just IDE0055 that we rely on ourselves.

roslyn/.editorconfig

Lines 144 to 145 in c18da5a

	# error RS2008: Enable analyzer release tracking for the analyzer project containing rule '{0}'
	dotnet_diagnostic.RS2008.severity = none

[CyrusNajmabadi]

At this point I am discouraged to report more because nothing ever seems to get fixed (usually because "it's complicated").

We do fix hundreds of issues. But there are a lot of things out there that people want fixed. So it's definitely possible that the set you care about isn't the set that always makes it into a release. The ones in this area are particularly thorny, and we lack a good mechanism to get high confidence that changes here not only make things better for these cases, but also do not make things worse for cases that others care about.

[FlorianHaupt]

This is really worse, what I read here. This misbehavior on tabs was reported shortly after the release of the VS2015 version, multiple times, by different people. Most of this reports were closed after a short period. I am quite sure, that everyone here knows about the license costs - I use a lot of cheaper software where the companies do not deal in such a bad way with their customers and fix such bugs when they get reported. Funny enough that this is open, the one reported on VS2017 Express.
You developed an new auto format engine and it fails to give the same good experience as the one that was used before and instead of fixing it, you prefer to spend hours of discussion with arguments that have nothing to do with the given issue. This is not understandable, a new engine has bugs and you do not feel the need to get it fixed? On top it is for the comfort in code editing and this is a bug that breaks the comfort in editing, creates unnecessary extra work – a very worse experience.
How much patience do you expect, by people that have to deal with this bug on every day?
I still remember that there once was really good bug handling within the visual studio team - seems that this is history.

[sharwell]

@FlorianHaupt For 75% of my career to date, I was a non-Microsoft developer working on projects primarily using tabs for indentation. The current behavior better represented the expected behavior for those projects, so on those projects I would have considered VS2015 to be the point where the bug was fixed, not introduced (note that I was not working at Microsoft for the VS2015 release where this behavior changed, so I was just a user). The complexity here is we're not talking about "fixing a bug", we're talking about introducing an option at a location that was never designed to be an option, and somehow getting both¹ behaviors to work seamlessly.

¹ This is a simplification, because in reality there are at least three very different behaviors being requested.

[Edgs]

@FlorianHaupt For 75% of my career to date, I was a non-Microsoft developer working on projects primarily using tabs for indentation. The current behavior better represented the expected behavior for those projects, so on those projects I would have considered VS2015 to be the point where the bug was fixed, not introduced (note that I was not working at Microsoft for the VS2015 release where this behavior changed, so I was just a user). The complexity here is we're not talking about "fixing a bug", we're talking about introducing an option at a location that was never designed to be an option, and somehow getting both¹ behaviors to work seamlessly.

¹ This is a simplification, because in reality there are at least three very different behaviors being requested.

What 'bug' are you talking about?
Please read the initial post again, and please stick to one topic per thread.
There is nothing complex about the BUG he is reporting. If that is what you are talking about, then please demonstrate another editor in existence which replaces tabs with spaces between code and comments. That is NOT expected behaviour.

If you are talking about something different then please split this thread as several quite different topics appear to be being discussed at once. Nothing will get fixed that way.

[sharwell]

@Edgs I'm referring to the same issue reported above. I'm not aware of another editor that works like this. When Visual Studio 2015 was released, I was happy to see it was the first editor to finally fix the behavior here.

Note that I'm definitely not saying everyone needs to agree with me. All I'm saying is if we put in a bunch of work to restore the pre-2015 behavior or come up with some new behavior that applies one way for all situations, some users will be happy and some users will not. The only thing that changed is it will be a different set of happy users than we have today, but from our side we're still going to be getting occasional reports about "it's broken".

[levicki]

We do fix hundreds of issues. But there are a lot of things out there that people want fixed.

That is just a proof that Agile (a.k.a. move fast and break things) approach to development doesn't really work as well as some people claim it does, and that internal QA team is necessary for development of quality software.

So it's definitely possible that the set you care about isn't the set that always makes it into a release. The ones in this area are particularly thorny, and we lack a good mechanism to get high confidence that changes here not only make things better for these cases, but also do not make things worse for cases that others care about.

I apologize in advance for the offtopic, but I have to point you and @sharwell to an issue I submitted in .Net Framework regarding Environment.SetEnvironmentVariable function.

The original issue was initially moved to .Net Core and marked won't fix for .Net Framework, and it was archived in the meantime. I'd like you to spend some time if you can reading the back and forth arguments there.

After you do that, please proceed to the issue they recreated for .Net Core initially, which has later been returned to .Net Framework runtime, and on March 28th it is going to be two years without resolution.

I'd also like you and @sharwell to spend some time to read my back and forth with Microsoft software engineers there.

You can see everything that needs improvement in the way issues are handled now at Microsoft -- from developer(s) not understanding the issue despite clear explanations, over them trying to find excuses not to change anything, over them not understanding the undelying platform behavior and original Win32 API, over developers of 3rd party libraries and tools chiming in saying issue should be fixed, to the issue resolution being endlessly postponed because "more discussion is needed" or "triage is needed" or whatever the excuse of the day is. I hope by now you are noticing a pattern, because the same kind of discussion is going on here as well.

And today here we are approx. 6 years since the release of Visual Studio 2015 where the issue was introduced and you are telling me that you need more time to make sure someone is not negatively impacted while people using tabs are negatively impacted for 6 years and counting.

If you do bother to read those discussions as I asked you to, you will hopefully see how much of my personal time and effort I have spent on submitting the issue, and explaining things that Microsoft's own software engineers should have known better than me. In case what I am hinting at isn't clear, the difference is that I am a customer who is paying for the OS and dev tools licenses who is spending own free time to help improve things, and your colleagues are doing this on the salary and with this kind of response I am getting I have absolutely no incentive to contribute further. On the contrary -- I have the urge to drop Microsoft products and suggest to the company I work for that we do the same wherever we can.

TL;DR -- I did provide feedback, I answered all questions asked by @jmarolf and @sharwell, and as far as I am concerned I did more than enough to help you understand the problem we are having and how you might solve it. I hope you prove me wrong and actually fix this issue, but I won't be holding my breath.

[Edgs]

So no other editor exhibits this behaviour, no editor before 2015 exhibited this behaviour, people are here reporting it as a bug, but you're are suggesting that it fixed some problem endemic since the dawn of computing. That's bemusing to me, but if you're happy with it, then lucky you. For everyone else, it's tough, because they can't turn it off if they choose to.

I'm not suggesting the behaviour is changed with no way for any user to keep their preferred style (which is actually what happened in 2015), just that the user options behave as advertised.

The formatting applied from the beginning of the line to code statements does follow the selected option - use spaces or tabs.
The formatting between code statements and comments does not follow the selected option - it always uses spaces.
It appears that the user option is ignored in this specific location. The location and 'tabulation' of the formatting is fine, just the characters used.

It is, lets say, disappointing that it sounds like Microsoft can't maintain it's code because it is too complex. If you just told me that this shouldn't be addressed because I was a nobody and my opinion wasn't important, I'd be annoyed, certainly, but overall less concerned.

[sharwell]

I'm going to pause comments again since this is getting longer but not likely to reach a conclusion on the current path. In the spirit of open source transparency, @CyrusNajmabadi and myself are attempting to explain the history of the current issue as well as the many different types of input considerations we face when attempting to resolve the issue. We understand that the current state isn't optimal for everyone, but honest risk evaluation makes it clear that alterations to address this issue will consume substantial time and engineering resources (always disproportionately large when working in the formatter) which directly translates to us not being able to use those resources to address other features, bugs, and overall product polish. As such, we have made the decision to leave this issue open while we work on other items that have broader customer impact.