Traditional Unix editors (emacs, vim etc) use a mix of tabs and spaces for indentation. The tab length is always assumed to be 8 and if the indentation size is different, indentation is created by inserting as much tabs as possible and inserting spaces for the remainder. Right now, in order to view such files correctly one needs to set the tab size to 8, convert the file to use only spaces and then set the indentation size to the correct value. However, when working on legacy code it is desired to keep the indentation method the same to avoid unnecessary commits. Therefore VSCode should support this method of indentation, auto detect it and allow to easily convert from and to it.
Steps to Reproduce:
Our current indentation was designed to help convert to only one type of indentation, more details about this can be found here. As a workaround for your scenario I suggest to set in your settings:
"editor.detectIndentation": false
Leaving this open as a feature reqeust
fyi @alexandrudima
I'm thinking we need to add a setting called fixedTabSize: true|false or something like that.
@eladts I wonder how other editors deal with this. i.e. Do emacs and vim offer an equivalent setting to switch behaviour?
I think such a setting should be applied per-file, not just glibally. As far as I know, Emacs always uses tab size of 8, there is no way to change that. I'm less familiar with VIM. In my opinion a separate indent size and tab size would provide a more generalized solution to the problem. This way you can set indent size to 4 and tab size to 8, for example.
Yes, vim allows you to set a different size for tabs (that already exist in the file), and indentation (how many spaces it moves if you press the TAB key). You can choose if the TAB key indents only with spaces, or if it should replace some spaces by a tab, if there are more than e.g. 8.
For example, in APT we indent at 3 spaces each, but every 8 spaces are replaced by a tab, so our indentation goes like this:
and so on. Both atom and vscode can't handle that, making it impossible to use them on such code.
JFTR: clang-format also uses the "IndentWidth" (how many spaces to indent) and "TabWidth" (how long a tab should be interpreted as), coupled with a "UseTab" option. Going the same approach for vscode would make a lot of sense given that you can then easily use the same settings for both without thinking much :)
So for example, for APT weird's indentation, we have IndentWidth: 3, TabWidth: 8, UseTabs: Always and it just works.
Vim allows specifying different values for both hard and soft tabstops, and can either use as many tabs as possible, or expand them all to spaces. It also has a separate setting for shift width, which roughly maps to the key combinations Ctrl+[ and Ctrl+] in VS Code.
Theoretically editor config also supports this use case, since you can specify a different indentation size from tabstop size. The plugin for VS Code supports setting both values, but it doesn't function as expected in this case; it just sets the tabstop size to the indentation size (if indent_style = space) or visa versa (if indent_style = tab).
Java code following the "Code Conventions for the Java Programming Language" is another use case for this feature. Section 4 - Indentation begins: "Four spaces should be used as the unit of indentation. The exact construction of the indentation (spaces vs. tabs) is unspecified. Tabs must be set exactly every 8 spaces (not 4)."
The GNU coding style also mandates indenting by two columns, using as many tabs as possible (where 1 tab is 8 columns) and the rest using spaces. So it's impossible to use vscode (or any other monaco-based editor) to work on these.
Just wanted to poke this issue as it still seems to be open.
I'm using Code as a wrapper for vim and I like everything about it, but I have to work on code written in vi(m) with tabStop=8 and shiftWidth=4 and there still doesn't seem to be the way to make it work.
Agreed, the Unix world learnt to use a fixed physical tabstop (of every 8 monospaced characters) a _very_ long time ago. It is the only way that generic tools (like XTerm or Powershell!) and text editors can reliably expand tabs in any file they come across.
The problem is that many Windows editors pretend they can flout the rules and cause many problems for themselves and others. A common misconception is that tabs can be any number of spaces and this can be used to change the indenting of a file. A little bit of thought shows that this only works if tabs only occur at the start of the line and are never mixed with spaces.
So at the moment vscode cannot deal with tabs correctly.
cfr. #42740
When can we expect this feature?
I also need this feature!
Yes, please get this done
I can't believe I found this 3 years old unresolved issue on Google.
I happened to write a bash script awhile ago and came across heredoc indentation problem. Example of my code is:
tee /home/user/test.log > /dev/null <<-END
this is line 1
this is line 2
this is line 3
END
I ended up having 4 leading space since it was not indented using tab. heredoc <<- was supposed to remove the leading spaces only if tab is used. Details here.
I don't want the whole document to use tab but only on the heredoc part and there is no way to mix it without entering the rest of the spaces manually... Not sure how to explain this, but that "leading spaces" will only get ignored when tab is used not space upon calling "<<-"...
Edit: Or perhaps this is actually bash' or heredoc limitation?
Just wanted to chime in here as well. A feature like this would put Code ahead of Sublime in my mind, they don't do this either and their general response is "fix your codebase" which is not feasible for larger projects.
It's beyond frustrating that this feature is not getting any attention from the vscode team at Microsoft. Or if it is, it'd be nice if they could give some indication of when/where it lands on the roadmap.
I am editing old .cgi scripts from 2001 and I find it baffling that vscode does not support combining tabs and spaces. Like ghost said, in heredoc parts it actually matters if it is spaces or tabs. Is there some great reason why it is not supported?
Here's another ping on this requesting a separation of tab size from indentation width. This will make it possible to use VSCode on projects that have coding standards requiring different tab size and indent width settings. Examples of codes being excluded include most FreeBSD (and style(1)) conforming codes, most of the GNU ecosystem, X11, and other stalwarts like the sources to Emacs and Vim themselves. This is related to request #42740.
To add another example of lecagy style documents that's hard to edit without separating the concepts of "indent size" and "tab width" are makefiles. In make, tabs are used not as generic whitespace, but as a special character representing a recipe line. To make them stand out, a traditional tab width of 8 is (almost) required. But you'd want the rest of the file formatted using space and a reasonable indent size (like 2 or 4).
Most helpful comment
Vim allows specifying different values for both hard and soft tabstops, and can either use as many tabs as possible, or expand them all to spaces. It also has a separate setting for shift width, which roughly maps to the key combinations Ctrl+[ and Ctrl+] in VS Code.
Theoretically editor config also supports this use case, since you can specify a different indentation size from tabstop size. The plugin for VS Code supports setting both values, but it doesn't function as expected in this case; it just sets the tabstop size to the indentation size (if indent_style = space) or visa versa (if indent_style = tab).
Java code following the "Code Conventions for the Java Programming Language" is another use case for this feature. Section 4 - Indentation begins: "Four spaces should be used as the unit of indentation. The exact construction of the indentation (spaces vs. tabs) is unspecified. Tabs must be set exactly every 8 spaces (not 4)."