Separate tab size and indent size

[bevolz]

Visual Studio Code have not appear to have the ability to do the Tools->Options Tab settings of Visual Studio Professional where you can specify that tabs are 8 spaces but the indent size if 4? All our code uses that style and many other editors let you do this, but Visual Studio Code doesn't seem to support this. I've tried lots of things in Visual Studio Code but not found any combination of settings that work.

Using Visual Studio Code 1.19.3 (and also Visual Studio 2015 (and Professional 2012)).

In Visual Studio, setting tabs at 8 and spaces at 4 means (for a blank line):

• Press tab key once, indent of 4 spaces.
• Press tab again, indent of tab (removes 4 spaces, adds tab)
• Press tab third time, indent is tab + 4 spaces.

[simark]

This is similar to GNU coding style (except it's two columns per indent instead of four), so enabling this would make it possible to use vscode for editing code of all GNU projects.

[lapo-luchini]

Ditto for standard Java style, but all of this is already discussed in #5394, this (almost exactly) a duplicate issue.

[dolangish]

I really wish a feature for separate tab size and indent size existed. As it is now, I cannot use vscode because it doesn't support tabsize = 8, indentsize=4. I find this odd because Visual Studio does support it.

[astrelsky]

Here is an example of why this needs to be implemented. This is beyond frustrating.

[brlcad]

Another ping in support of this feature. For anyone curious, the rationale was recently discussed for the Atom editor as it similarly lacks this concept from Visual Studio, Emacs, Vim: atom/atom#21371

[magicus]

Without this functionality, editing Makefiles is hard, since tab is used as a special character in make recipes, which you'd want to have clearly standing out by using a tab width of 8. But this does not conflict with the fact that you'd want a smaller indentation (e.g. 2 or 4), using spaces, in the rest of the makefile.

[dolangish]

Just dropping in to ping this issue. I've been following it for years now hoping it would get implemented at some point. I currently get by using vs code by formatting the document using a formatter that converts all tabs to spaces. This is not an ideal solution and it'd be great to see this feature implemented to work in a similar way to visual studio. I'm actually at a bit of a loss as to why it's lower on the priority list than some of the other issues that have been tackled. Please address this!

[adrian-constantin]

I would very much need this too, in my current project.
Hope it gets implemented soon

[ongun-kanat]

I am quite surprised that VScode lacks this feature. I think among the universe of editors only KDE's Kate handles this correctly, even Vim sucks at mixed tab and space indents. However to add the original comment of @bevolz this feature should have three options / levels:

• Indent with spaces
• Indent with tabs
• Indent with tabs + spaces

In those options the action for pressing TAB key with a 4 space indent size and 8 space tab size should do these respectively:

• Insert 12 space (' ') characters
• Insert 3 tab ('\t') characters
• Insert 1 tab and 1 space character

Otherwise the implementation with mixed tabs and spaces will be a great way to ruin the day of Python programmers.

[poosh]

+1
We have a lot of legacy code that mixes tabs with spaces, and tabs are considered 8 spaces, while a single indent is 4 spaces (TAB = two indents).

In Atom editor I had a CSS hack to draw TAB as 8 characters while the editor was still thinking it is 4-char long:

atom-text-editor .invisible-character.hard-tab {
    margin-right: 4ch;
}

Since Atom has been discontinued, I want to migrate to VS Code fully. Unfortunately, I have to return to Atom whenever I access the legacy code.

[zeroimpl]

It seems this feature was already implemented 3 years ago, but was partly reverted simply because people couldn't agree on the name of the property.
See #10339.
Perhaps somebody could just revert this commit e2049cd and then we can finally use it?

There's plenty of duplicate tickets for this, such as #5394 and #135058 so I think there's gotta be enough support to prioritize this feature.

[timll]

Awesome to see progress on this, thanks @zeroimpl. Do you also plan to include that every n spaces convert to 1 tab automatically?

[magicus]

@timll At this point, I think the most important part is getting the distinction between tab size and indent size into the code base.

Things like converting spaces to tabs can be extended later on; in fact, how to properly convert between spaces and tabs can be contested and language-specific; for instance, should you convert only leading spaces, or also spaces e.g. in front of a trailing line comment? So better keep that discussion separate.

[chrisant996]

The clink project uses code from GNU Readline, and Readline uses tabwidth=8, shiftwidth=4. Readline code is unreadable in vscode.

I would dearly love to see vscode gain the ability for tab width and shift/indent width to be different.

[brlcad]

From the discussion in PR #155450 this issue should not have been closed. That PR doesn't satisfy the second bullet, which is critical to the proper behavior of mixed tabs+spaces. Having tab always inject spaces regardless of the tabsize setting is incorrect behavior.

[magicus]

@brlcad That is not necessarily incorrect behavior, though I acknowledge that it might be incorrect behavior for your use case. For me, editing huge makefiles, where space and tab are semantically different, and the long-standing convention has been that tabs expand to 8 spaces, but code is logically indented by two spaces, it really is the correct behavior.

(Not trying to diminish your situation; just pointing out that this change was not worthless)

[chrisant996]

From the discussion in PR #155450 this issue should not have been closed. That PR doesn't satisfy the second bullet, which is critical to the proper behavior of mixed tabs+spaces. Having tab always inject spaces regardless of the tabsize setting is incorrect behavior.

Oh no! Correct -- this is still very incomplete, then.

In a file where "indent with Tabs" is enabled and indent is 4 and tabwidth is 8, then one press of Tab should insert 4 spaces, and a second insert of Tab should end up recognizing that 8 spaces will be equal to 1 tab, and should replace the 4 spaces with a tab character.

[chrisant996]

@brlcad That is not necessarily incorrect behavior, though I acknowledge that it might be incorrect behavior for your use case. For me, editing huge makefiles, where space and tab are semantically different, and the long-standing convention has been that tabs expand to 8 spaces, but code is logically indented by two spaces, it really is the correct behavior.

(Not trying to diminish your situation; just pointing out that this change was not worthless)

@magicus, @brlcad didn't say it was "worthless". The statement was that the behavior is not yet correct. Which is an accurate assessment.

It's great that at least display works now.
But it's frustrating if editing still doesn't work properly.

[brlcad]

@magicus I'd argue that it's inconsistent and thus incorrect in comparison with existing editors that support mixed indentation+tab width settings. Emacs and Vim, for example, handle Makefile indentation with separate mode and settings respectively as tab is baked into the file format. To make that behavior default will likely result in awkward settings for the lionshare of C/C++ code wanting support as described by this issue's bulleted points.

Not satisfying this issue's criteria was also the primary point. I'm not arguing whether the PR has value for other cases. The PR that was used as justification to close this issue does not satisfy this issue's second itemized bullet which described specific expected behavior.

[timll]

From the discussion in PR #155450 this issue should not have been closed. That PR doesn't satisfy the second bullet, which is critical to the proper behavior of mixed tabs+spaces. Having tab always inject spaces regardless of the tabsize setting is incorrect behavior.

At least as a short-term fix, you could run the unix unexpand command on the edited files (possibly with a task that triggers on save).

[chrisant996]

From the discussion in PR #155450 this issue should not have been closed. That PR doesn't satisfy the second bullet, which is critical to the proper behavior of mixed tabs+spaces. Having tab always inject spaces regardless of the tabsize setting is incorrect behavior.

At least as a short-term fix, you could run the unix unexpand command on the edited files (possibly with a task that triggers on save).

I have several ways I can manually compensate. It's frustrating and time consuming to take the compensating actions (or to write an extension to do it).

What I would be most likely to do is one of these:

• Write an extension which upon saving a file automatically fixes overly-long runs of 2+ spaces but only in modified lines so that they use proper mix of tabs/spaces. However, that's only a heuristic and is susceptible to both false positives and negatives -- converting typed spaces into tabs (wrong), and not converting single spaces into tabs when the tab key had actually been pressed.
• Write an extension command that can be bound to Tab and does the proper optimized mixed tabs+spaces representation to replace the run of whitespace preceding the insertion point. But it needs to play well with multiple selections and cursors, and various contextual situations where Tab may be pressed. Ideally VSCode should have that built in.

[alexdima]

Reopening since the replacing as many spaces as possible with tabs part is not implemented via #155450

[jelmd]

Haven't touched an IDE for about 5+ years, so thought it might be a good idea to give VScode a try: completely wrong, what a big disappointment. Formatting is really a nightmare especially wrt. tab handling and lang specific settings do not exist or do not work at all. 10+ years ago eclipse was even better than this. So I'll ditch this stone age thingy and recommend our students to use Eclipse or IntellJ.

[astrelsky]

Haven't touched an IDE for about 5+ years, so thought it might be a good idea to give VScode a try: completely wrong, what a big disappointment. Formatting is really a nightmare especially wrt. tab handling and lang specific settings do not exist or do not work at all. 10+ years ago eclipse was even better than this. So I'll ditch this stone age thingy and recommend our students to use Eclipse or IntellJ.

This has now been fixed, the tab stuff at least. I don't know anything about the language settings though.

[gabezal]

@astrelsky It is not fixed. I am on the latest version and cannot find a way to configure VS Code to work as described in the original issue description:

Press tab key once, indent of 4 spaces.
Press tab again, indent of tab (removes 4 spaces, adds tab)
Press tab third time, indent is tab + 4 spaces.

If there is a way to achieve this, please let me know, because it seems to be either too obscure, or something that is implemented by some extension that I'm missing?

I've set the "editor.indentSize": 4 pref everywhere I possibly could (in each of the user, workspace and folder settings.json files), yet when I press TAB on an empty line, it still inserts a tab (equivalent to 8 spaces in my current configuration) instead of a 4-space indent. It's only supposed to insert a tab once I press TAB a sufficient number of times (when enough indenting spaces accumulate to fill the size of a tab).

I've just updated to v1.76.2, and I've been looking into whether this is fixed for a long time now. It still doesn't work as described.

Just a note: the above described behavior is with Eitor: Insert spaces disabled. If I enable it, I get a partially "correct" behavior: it only ever inserts 4 spaces every time I press TAB, but the expected behavior is to also convert the existing indentation spaces to tabs. I wouldn't consider this fixed yet.

[astrelsky]

I wouldn't say that is the expected behavior unless it is documented to do so. As far as I know there is no feature to do so but I think it would be possible to do with something like the trim trailing whitespace on file save feature.

[gabezal]

@astrelsky If you want to get into semantics, it is the behavior that is being requested to be implemented as a new feature in the current issue (notice the feature-request tag).

It is not (or less) desirable to have this done as a part of file saving. There are situations where you also want to have a non-conforming indent (one that does not adhere to VSCode's configured indenting rules), and implementing this feature as part of "Save File" (i.e., reformatting the whole file on save) would disallow that use case, potentially introducing unwanted/pointless merge differences which most developers don't like to deal with during code reviews. It's better to leave the file alone at save time and just apply the indenting rules at edit time, only for the edited lines.

I'm not trying to nitpick or anything. These are just rules that most projects tend to follow. Leave existing formatting alone, and just apply the user's settings as they type.