-
Notifications
You must be signed in to change notification settings - Fork 29.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for mixed tab/spaces indentation #5394
Comments
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: Leaving this open as a feature reqeust |
I'm thinking we need to add a setting called @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. |
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 spaces are only ever used as lone characters so you cannot align things anywhere except the indent. So at the moment vscode cannot deal with tabs correctly. Edit: Clarify the rules for "any-width" tabs in files. |
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:
I ended up having 4 leading space since it was not indented using tab. heredoc 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). |
I would like the features as well. My example is GCC compiler, where we mix spaces (we indent by 2) and tabs (equal to 8 spaces). |
Just for the record, the Atom editor has the very same limitation: atom/atom#21371. Not being a vscode developer, I briefly grepped for |
Bump. Please make shiftwidth: and tabstop: work with embedded modelines as well. |
Done via #155450 |
@alexdima, does that PR address this requirement?
From the discussion on the PR:
it sounds like the PR does not really address the issue. We could already display files correctly by setting tab size to 8. The issue is that when you start editing the file, you start to mess it up by not mixing tabs and spaces correctly. My previous workaround was to manually insert tabs and spaces as needed (or use a different editor). |
Does |
PR #155450 has information on the thought process. It seems like an important step for supporting alternate indentation styles, especially the GNU "hard tab-stop" style. But I agree that without the changes to indentation style (such as replacing In other words, the PR addresses the issue, but it alone does not fix the issue. |
Agreed, my PR #155450 doesn't fully address this issue. As a proof of concept, I've implemented a quick fix that seems to do what folks want, in terms of allowing mixed indentation that continues to insert both tabs and spaces: zeroimpl@ba9ac4f, https://github.com/zeroimpl/vscode/tree/zeroimpl/mixed_tabs i think it needs some more work to fully productize though. There's a normalizeIndentation function used in a bunch of places that likely needs updating. The UI/status bar probably needs some adjustment. Documentation should be updated too. I don't know enough about the code base to make all the relevant changes though. |
Reopening since #155450 doesn't address the replacing as many spaces as possible with tabs part. |
Annual ping, any update? |
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:
The text was updated successfully, but these errors were encountered: