bug: tabSize affects indentation

[cblp]

• VSCode Version: Code 1.4.0 (6276dcb, 2016-08-04T16:49:32.489Z)
• OS Version: Linux x64 4.4.0-34-generic

tabSize setting has two independent functions:

1. Size of tabulation character.
2. Size of indentation.

The latter is really useful. But its connectedness with the former makes it unusable. In one file tabulation character size may be 8 and indentation size may be 4. How can I control these two values with one setting?

[rmunn]

In one file tabulation character size may be 8 and indentation size may be 4. How can I control these two values with one setting?

@cblp Have you tried the EditorConfig plugin? It's written for exactly this scenario. See http://editorconfig.org/ for more details.

[cblp]

Yet another plugin and yet another configuration file for a single option? Okay :(

[cblp]

No, EditorConfig doesn't fix the issue. When I configure it to

[*]
indent_size = 2
tab_width = 8

it changes both indentation size and tab size to 2.

I think, EditorConfig can't work properly because of this issue.

[gcp]

This bug also makes proper handling of mode lines an issue, see for example ctlajoie/vscode-modelines#1.

[marktucker]

This issue makes it impossible for me to use VS Code as an editor on our existing library of code (which uses vim soft tabs of 4 spaces to indent, but a tab size of 8). With this fixed I could replace all my terminal windows, Vim, and Visual Studio with VS Code... Pretty please?

[greggman]

Another vote hoping this gets some TLC. I've been using tab stops of 4 but indenting of 2 spaces for many many years.

[jochumdev]

I also realy would welcome this to be fixed.

[Wintaru]

I'd like to vote for this to be fixed as well. I tried the EditorConfig extension, and when I reload the window it indeed "fixes" the issue (shows tabs with the correct spaces I put in .editorconfig, 8) but as soon as I click on another file and then back to the original, Code resets the tab width back to 4 (which weirdly, is not what I have in Code's default configuration for Editor:Tab Size, I put 8 there too).

Edit: fwiw detect indentation is off too. I have no idea where Code is getting this tab size now, or if it just defaults to 4 for some reason?

[trusktr]

If I understand correctly and am in the right place, this is important for develop experience. For example, some people really like to view code with indentation being at the width of four spaces. Regardless if the underlying code is actually using 2-space indentation, the developer wants to view it with 4-space indentation (equivalent of tab characters set to 4 spaces wide) to make the development experience better. However, VS Code does not allow this, instead, VS Code always modifies the underlying code to match the developers viewing preference, which is undersirable when collaborating with other people who may rely on the 2-space indentation.

Basically what we need is to control how the code is actually formatted, and to control how we view the code, such that if we open the code in a simple plain text editor we would see 2-space indentation, but in VS Code (with appropriate settings) we would see it as 4-space-tab-like only for developer convenience.

Is this what people are asking for?

[marktucker]

I don't want to speak for anyone else, but what I want is much simpler than this, I think. Actual "space" characters should be sacrosanct, not considered part of some "indentation" that the editor tries to interpret. All I want is that a tab character be allowed to move to the next columne that is a multiple of 8, which at the same time have my "indent size" for automatic code formatting set to 4 spaces (real space characters, no tab characters).

For me, the use case is dealing with an old code base filled with a mix of tabs characters and space characters (but with a consistent indent step size of 4 columns, populated as either space characters or size-8 tab characters) looks right in the editor. And I can edit these files without reformatting/editing every single line (automatically or not) without polluting my version control system with useless edits to the code spacing.

[Wintaru]

What @marktucker said. I would like to be able to set tab characters to 8 spaces but when I hit the tab key want it to indent 4 spaces. My use case is the same as his.

Before anyone says "well fix the code base" 1) 30+ people work in this and it is millions of lines. 2) VIM, Emacs, and Eclipse can all do what we are asking for here, I am one of two people that use VS Code and making a huge whitespace commit for just us is not feasible when 3) some of our developers have not and seemingly will not configure their editors to use spaces instead of tabs so the whitespace commit would be ruined as soon as one of them pushed something.

[scigor]

Same usecase here as @marktucker and @Wintaru. I hope this gets higher priority, because this is the reason vscode does not get higher adoption at the company i am working at.

[Timmmm]

It's a bit confusing that both settings still exist internally in the VSCode. If I'm adding a new feature do I just use tabSize for everything or should I try and do things "correctly" using indentSize and tabSize?

I think having two settings is overkill and I haven't heard a compelling reason to have tab size different to indent size. Legacy code can easily be fixed with sed or an automatic formatter (even if it is a million lines @Wintaru), and I don't think VSCode should greatly complicate itself just to support really really unusual code styles.

[Wintaru]

It's a bit confusing that both settings still exist internally in the VSCode. If I'm adding a new feature do I just use tabSize for everything or should I try and do things "correctly" using indentSize and tabSize?

I think having two settings is overkill and I haven't heard a compelling reason to have tab size different to indent size. Legacy code can easily be fixed with sed or an automatic formatter (even if it is a million lines @Wintaru), and I don't think VSCode should greatly complicate itself just to support really really unusual code styles.

I’m sorry you think this is confusing but Vim, Emacs, Eclipse, and other major editors support this. If it is already an internal setting why can’t we expose this to settings and let us set both? Your excuse doesn’t fly with me, sorry.

[marktucker]

Automated updating of a huge, old code base isn't impossible because the scripts are hard to write, but becuase running those scripts and committing the results erases, or at least obscures and greatly complicates access to 25 years of svn blame history as in one commit 90% of the lines in the code based are changed by these scripts. That is a price I cannot pay just to be able to use VSCode.

[Timmmm]

I’m sorry you think this is confusing but Vim, Emacs, Eclipse, and other major editors support this.

You misunderstand. I meant it is confusing when developing VSCode itself that both settings exist internally in VSCode, but it actually only supports a single setting.

running those scripts and committing the results erases

Clearly not.

or at least obscures and greatly complicates access to 25 years of svn blame

Actually, just for converting all tabs to spaces you could avoid a big whitespace modification commit by rewriting history and running the script for every commit. Might take a while but git has built in support to do it automatically (filter-branch).

In any case, I still don't think it is worth the extra complication just to support the "I don't want to use git blame -w" use case.

[rmunn]

I think having two settings is overkill and I haven't heard a compelling reason to have tab size different to indent size. Legacy code can easily be fixed with sed or an automatic formatter (even if it is a million lines @Wintaru), and I don't think VSCode should greatly complicate itself just to support really really unusual code styles.

The compelling reason, which may not feel compelling to you but is compelling to many people, is that many tools (including some languages) are hardcoded to treat Tab characters as being 8 spaces wide. For example, Python 2 and Python 3 both treat a Tab character as meaning "one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight (this is intended to be the same rule as used by Unix)". Note that Python 3 adds the rule "Indentation is rejected as inconsistent if a source file mixes tabs and spaces in a way that makes the meaning dependent on the worth of a tab in spaces; a TabError is raised in that case," which means that mixed tabs-and-spaces files will cause a syntax error in Python 3 until the codebase is fixed to be consistent. But for codebases using Python 2, where four-space indents are the norm but someone in the project has created a file containing tab characters (which is equivalent to eight spaces, i.e. two indentation levels), it's crucial that tabSize be left at 8 while indentSize needs to be 4 in order for the existing code to be displayed and edited correctly.

And the suggested "just rewrite history with git filter-branch" solution is a non-starter for many projects. That will change every commit hash, which would end up causing all sorts of links (GitHub PRs, mentions of commit IDs in Git history such as reverted commits) to go dead. That's far more costly than having two settings in an editor, one for tab size and one for indent size. Those two options should not be the same value in many projects, and a decent editor should be able to handle that use case.

[Timmmm]

Good point about links being invalidated. However I think Python's mad indentation rules are irrelevant. Nobody mixes tabs and spaces in Python code precisely because it is so hard to reason about.

[mcornella]

1. The name. "visualTabSize" has been suggested. My personal opinion is that it would be nice to try to be consistent with other major editors. This isn't really possible because of the fact that the most important aspect of the existing "tabSize" setting is the indentation, so the meaning can't be the same as Visual Studio and Eclipse. However, I kind of like "tabstop" from vim since the visual width of a tab character could actually be less than 8 characters (or whatever the setting is set to).

I think using tabstop or tabWidth makes sense (for consistency with EditorConfig), but having two settings named tab* will be confusing, so I think you should also use indentSize and deprecate tabSize (and if indentSize isn't set, use tabSize instead). This requires a transition, which is harder to do, but I don't see tabstop and tabSize coexisting without significant user confusion.

[jednano]

I haven't heard anyone yet make the distinction between indentation and alignment. Ideally, a document would only use tab characters for indentation and spaces for alignment.

If I were building an editor from scratch, I would keep the word "tab" out of the setting name and start with something like the following:

interface EditorSettings {
  /**
   * Each indent is represented by either a single tab character or a specified number of spaces.
   */
  indent?: 'tab' | number;

  /**
   * Visual width for each level of indentation.
   * @default EditorSettings['indent']
   * @example an `indent` of `2` and an `indentWidth` of `4` would make each space in the
   * indent range appear as `2` spaces of width. Conversely, an `indent` of `4` with an
   * `indentWidth` of `2` would make each space character appear at half width.
   */
  indentWidth?: number;

  /**
   * In alignment regions, each Tab key press inserts a tab character.
   * @default false
   * @warning changing the indentation width will break the alignment if this is `true`.
   */
  alignViaTabs?: boolean;

  /**
   * If `alignViaTabs` is `false`, pressing the Tab key within alignment regions produces the
   * correct number of spaces to land on a column number that is divisible by this number.
   */
  tabStops?: number;
}

Related issues

• Smart tabs - Feature Request
• EditorConfig | Smart Tabs
• tab_width and indent_size shouldn't be mutual exclusive editorconfig/editorconfig-vscode#190

[alexdima]

Done via #155450