Disable autoindent

[cfjedimaster]

• VSCode Version: 1.0
• OS Version: OSX

Currently there are multiple ways to configure indention, but no way to disable auto indention. For example, I enter <p>, hit the enter key, and on the next line the cursor has indented. I want to disable that.

[alexdima]

@cfjedimaster We have an open PR #5423 that would make it that pressing subsequent Enter, the inserted whitespace gets trimmed.

Also, are you finding this behaviour annoying in a certain programming language, or when doing something specific, most of the feedback we got so far is that indenting to the right spot is a helpful feature, and not an annoyance, so I'm wondering if you're hitting a use-case where this doesn't work as expected.

[cfjedimaster]

I'm finding it only an issue in HTML, maybe because I tend to have specific ways of indenting in HTML, specifically I keep head and body at the same level as html. #5423 doesn't look to be exactly what I want - I really just want no white space inserted at all. I hit enter, and my cursor will be at position 1 in the next line.

[cfjedimaster]

Another example - given form fields where I'm wrapping each label and input in a particular div, I like to have them all at the same indentation level.

[Luminoth]

I'd like to second this feature request. Right now not being able to turn that off is the only thing stopping me from using VSCode as my main editor.

[maximecb]

Would also like to be able to disable auto indent. I generally don't like automatic behaviors that try to guess what I want to do, because they often guess incorrectly.

[peredin]

Just like others have already mentioned this "feature" is quite annoying. I dislike any kind of automatic behavior that cannot be turned off. If I want to indent a line I will use the tab key manually.

[ste2425]

Auto indenting is also quite annoying when working with projects that enforce the no-trailing-spaces rule of ESlint and others.

The auto indenting instantly fails this rule.

[roman01la]

I'm using Parinfer plugin to auto balance Clojure code. Auto indentation on Enter press doesn't allow Parinfer to place a cursor into inferred position.

[Kobnar]

There's the pretty obvious use case of editing raw text.

I understand vscode is a code editor, but it's pretty silly that I have to switch to a different application if I want to write normal text with typical, first-line indentation standards. Otherwise, I have to trip over an auto-indent feature that can't be turned off.

[ajbogh]

Any information on whether this feature was implemented, or maybe a workaround to disable auto-indentation? I'm working on a React project where the indentation gets confused when HTML is inserted into the js files, even though "Javascript React" is chosen as the file type. I'd rather disable auto-indentation and indent manually, or at least use same-level indents where the editor doesn't try to tab the next line in, instead it attempts to maintain the same level of indentation unless the user presses the tab key to indent further.

[aclarkxyz]

This certainly seems to be the IDE trend these days, but it is profoundly annoying: having really basic auto-indenting to the same column as the previous statement is great, but having the level jumping back & forth as you type, or presuming you want an extra one, is a pointless productivity killer. VSCode is a fantastic tool in general because it's lightweight and relatively simple - not cluttered up with a trillion features that think they know more about programming than you do - but we really need to be able to switch off some of the extra fancy stuff.

[cfjedimaster]

I'm confused -the last update supposedly adds indent stuff (https://code.visualstudio.com/updates/v1_14#_auto-indent-on-type-move-lines-and-paste) yet I still can't disable auto indent, even with editor.autoIndent:"false".

[quanticle]

editor.autoIndent controls whether the editor with indent or unindent based upon the indentation rules defined for the language. So, for example, you can define a rule for python that indents in on ":\n", and then out-dents on "return".

Setting editor.autoIndent to false disables that particular form of autoindentation, and then causes VSCode to revert to the older form of auto-indenting, where it keeps the next line at the previous line's level of indentation. It does not disable autoindentation entirely.

Personally, I think the flag is mis-named. I would have called it something like "editor.followIndentRules" or something similar rather than "editor.autoIndent".

[cfjedimaster]

For me, in HTML at least, it is auto-indenting. So it isn't staying at the same level. Either way - it sounds like it is a bad name as you say.

I find it a bit frustrating that other stuff was added in regards to indentation before being able to completely disable it.

[codenamezjames]

Is there a status on this??

[auchenberg]

Question on StackOverflow has passed 750 views. https://stackoverflow.com/questions/36664324/how-to-disable-autoindent-on-enter

[Rhywun]

I don't mind the behavior where pressing Enter keeps the next line at the previous line's level of indentation. But that should only happen the first time you press Enter. I can press Enter ten times and I get nine blank lines followed by a line indented at the level of the line ten lines up. That's madness. That sort of indentation is not useful in any language that I'm aware of. The second time you press Enter without typing anything, the cursor should be positioned at column one.

[rcook]

I think this behaviour is particularly problematic with programming languages like Python and Haskell where the autoindent often (nearly always) produces invalid or semantically different code.

[mainakk]

It is also problematic with Scheme (and Scheme-like languages). It doesn't let format code in the following way:

(define f
  (pp 1)
  )

It changes it to:

(define f
  (pp 1)
)

[bertfw]

It should be possible to disable this auto-indent feature entirely, meaning that when you hit Enter the cursor is positioned at column 1 on the next line. I'm hardwired to hit tab when I know I'll need an indent, so having the editor forcibly add an indent is infuriating. There are times when keeping the previous level of indentation could be a positive thing, but these are so far and few between that using select-block-tab is just as good, making auto-indent rather pointless.

In fact I'd even say that in general, the control of anything "autoformat" should be left to the end user.

[aclarkxyz]

There should really be 3 settings for autoindent:

• nothing (rewind to column 1)
• smart (try to guess what the user wants)
• keep (indent to same position as previous line)

I can't imagine anyone would feel left out if all of these were available as configuration choices. The default can be whatever is most popular.

[thenexus00]

I am having this issue mainly with the CSS. Every time I add a new CSS line it starts indented instead of a new line. Here is just one example:

It actually gets pretty frustrating :(

[ghost]

From my understanding you are saying that every time you save VSCode is auto indenting? If it is auto indenting check all your braces to make sure they are closed. This problem occurred in a css file and after a quick debug I found out one of my braces was not closed causing my entire file to auto indent every time I saved. To help find unclosed brackets I recommend installing the extension " bracket pair colorizer ". Hope this helps.

[thenexus00]

It is not to do with the code in terms of errors but rather the CSS format. VSCode right now only considers the designer style format and not other format conditions like single line Pico structure. I am even seeing similar issues with Flutter (Dart) as well during mobile apps and even if your doing standard formats.

…

On 24/7/18 9:24 am, andrewriveraj wrote: From my understanding you are saying that every time you save VSCode is auto indenting? If it is auto indenting check all your braces to make sure they are closed. This problem occurred in a css file and after a quick debug I found out one of my braces was not closed causing my entire file to auto indent every time I saved. To help find unclosed brackets I recommend installing the extension " bracket pair colorizer ". Hope this helps. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5446 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEHOUJ33Rs6cZ6AZiaw2zAXoHRdyPHUEks5uJlsrgaJpZM4IJo-P>.

[bertfw]

Hi Andrewriveraj, It doesn't have to do with save. Whenever hitting "Return" to create a new line it autoindents the new line even if all indenting options are disabled. This does not seem to be an issue on the Windows version, at least not in my experience - only OS X. I have not tried the Linux version.

[aclarkxyz]

But now if you switch off the 'Auto Indent' flag in the settings, most of the really intrusive behaviour stops.

@aclarkxyz What version is that? Here it doesn't change at all.

Versione: 1.40.1
Commit: 8795a98
Data: 2019-11-15T22:58:14.270Z

Two issues, I think. Now and at all times in the past, it will add an extra indent level for you under certain circumstances. Personally I do not like this (and that's the opinion of everyone else on the thread too), but I have made my peace with it: I have so few other complaints that I can learn to live with this relatively minor nuisance. And since almost every other modern editor is so much worse, I figured I'd just call this a win.

The other issue is that there were several releases where it was severely broken for anyone who doesn't use one of the wretched misaligned-brace styles: it would guess your indent level (wrongly), and then adjust it to something else as soon as you typed a character. It was totally unusable, and the only solution was to hack some of the source files after each release. This did eventually get fixed. If this sort of thing happened on a regular basis, I'd be full of rage, too... but fortunately it doesn't!

[David263]

Alex, I think you are remarkably, amazingly tolerant. I'm not. My software tools must work, they must work well, they must further my productivity, and they must not cause repeated frustration. If they do, I report bugs. If the organization that supports a tool does not believe in fixing bugs unless they are so extreme that the tool cannot be used, I abandon the tool and the organization, not because I want to but because I must.

In the case of editors and browsers, for some reason (as opposed, say, to javascript frameworks or string conversion tools), organizations appear to tolerate bug reports of many years' duration. This is well beyond my understanding: computers are supposed to make our life more fun, not give us frustration, and developers are supposed to fix bugs, not rationalize their continued existence. VSC is supposed to be a new product, yet it acts like a product bent over with rheumatism, hobbling around like an old man (I'm 73 years old and I can still find and fix bugs).

You and I live in different worlds so far as our philosophy of software tool maintenance is concerned. That would be fine if the stakes were not quite so high. But I will not compromise on software tool usability. Life is too short to live in frustration.

Although it is true that few of the software tools I have created have had any bugs, I have always fixed my own bugs quickly (I posted that already; you may have noticed). Why can't others fix their bugs as well as I did throughout my 40 year career? Is it laziness, or the fact that these developers leave too many bugs behind, or write unmaintainable code? There has to be a reason.

In the software industry, we implement in stages. We first create a design specification and review it, so problems can be caught early, where they are easier to fix. Then we unit test and do code reviews (I'm abbreviating) so coding bugs can also be caught early, where they are easier to fix.

I see no reason why using an Open Source approach to collaboration has to produce many unresolved bugs, or has to result in justifying the continued existence of bugs years after they have been reported.

There is something broken about how VSC was created and/or is now supported.

I'm not filled with hate, as you first supposed, and I hope you appreciate that I am presenting balanced opinions, not incivilities or anger. I'm simply explaining that something is wrong with VSC support and that I cannot adopt VSC in spite of its many reliable and well-thought-out and well implemented features.

There is just no excuse for not fixing bugs (defined as receiving bug reports from various users), especially the amazing excuse that the feature used to have an even worse bug that was fixed.

[madprops]

"There is just no excuse for not fixing bugs"

They don't owe you anything.

I came here because I'm trying to disable autoindentation on a file, not globally.
Auto indentation is incredibly useful though.

[David263]

"They don't owe you anything" Well, that's true. But if a great product has one particular glaring bug, one that has been reported again and again for years, but the supporters seem to refuse to fix it, why shouldn't I complain?

You are welcome to believe that autoindentation is useful. In 50 years of software engineering, I have never wanted autoindentation. The Enter key should just do a CR and LF, nothing more. If you want indentation, you should use the Tab key. I find autoindentation particularly annoying when editing text files, but it always interferes with my productivity.

That is what options or preferences are for: to accommodate different needs and ways of working. But VSC's "autoindention off" option doesn't work, and apparently they won't fix it.

Your turn.

[madprops]

Would be nice sure, but there might be reasons this hasn't been worked on. Maybe other stuff is priority right now. Every month there are tons of updates in the changelog. Also, it's an open source project, meaning you can fix it yourself if you want.

[redtide]

Would be nice sure, but there might be reasons this hasn't been worked on. Maybe other stuff is priority right now. Every month there are tons of updates in the changelog. Also, it's an open source project, meaning you can fix it yourself if you want.

So low priority that after 3 years and half and 50 comments on the issue nobody gave it a shit :D

[Neonit]

Would be nice sure, but there might be reasons this hasn't been worked on. Maybe other stuff is priority right now. Every month there are tons of updates in the changelog. Also, it's an open source project, meaning you can fix it yourself if you want.

And I think it's about time to explain these reasons here and now.

[alexdima]

Hi everyone, I want to apologize for my silence on this issue. I personally unsubscribe from feature requests in my areas because I cannot handle the volume of comments. I am just overwhelmed by comments otherwise, and I am an incredibly slow reader and writer of comments.

We try to incorporate community feedback as much as possible into our planning, and we look at the most popular feature requests when planning. Unfortunately, this issue is not in the top 100.

Please also consider that we are an open source project and it is always possible to submit a PR implementing the desired functionality. A PR, especially a well written one that can be merged immediately, will greatly expedite a feature request shipping in VS Code.

This issue is marked as a feature request and not a bug because the current code works as intended. That is, the code matches the desired intent and this issue does not identify a flaw with the code. In other words, the code correctly preserves indentation, or indents when having an open bracket, exactly as desired when we looked at how Enter should behave. We treat bugs differently than feature requests and we never have unassigned/unsubscribed bugs.

Finally, I agree that we should have an option controlling this behavior and I'm sorry for disappointing you on this issue.

[redtide]

@alexandrudima an option to disable a feature that doesn't work IS a bug, not a feature request.

[geekley]

Here's what I dislike about the current way VSCode does indentation (at least in .js files):

const app = connect()
  .use(fn);

If I press enter after the ;, the next line will have the same indentation as the that line. Even after removing the indentation on this line, when I press enter again, the next line will have that indentation again. This kinda seems like a bug to me.

[alexdima]

This thread has captured several distinct problems... The current implementation for handling Enter in the editor is a bit complex and influenced by quite a number of things:

1. onEnterRules -- these are language specific rules. For example, this is the mechanism through which pressing Enter in a JSDoc comment will maintain the *, which is specific to JS:
   

2. brackets -- each language can define its brackets. This is the mechanism through which pressing Enter after an open bracket or inside a bracket pair will indent or, respectively, indent-newline-outdent:
   

3. indentationRules -- each language can define its indentation rules. These rules are applied in a number of places, like when pasting, or moving lines. Since indentationRules are regex based and thus cannot be always correct, there is a setting "editor.autoIndent", which can disable them.
   

4. if none of the above applies, the indentation is maintained on the new line.

---

Here I will try to sum up the concrete problems mentioned in this issue:

Pressing Enter in HTML after an element like <p> indents unexpectedly

In this case, the indentation is increased via onEnterRules. This is caused by this specific HTML onEnterRule.

Pressing Enter should insert only \n and nothing else

In this case, the indentation is maintained. This is caused by the fallback of maintaining the current indentation on the new line.

---

There are other comments which mention problems with Clojure, JSX, Python or Haskell, but which are unfortunately imprecise, so I could not distill any clear steps on enter from them.

---

TL;DR - Currently, the Enter logic has 4 discrete "plugins" that tweak what happens. Out of the 4, only one can be disabled via editor.autoIndent.

The challenge is to come up with an editor option which would allow turning on/off the 4 "plugins" individually.

[David263]

alexandrudima, I do sympathize with your unsubscribing due to the volume of bug reports. But fixing the bug is a much better response to a popular bug. It gets the bug reports to stop, which is better than ignoring them.

"I agree that we should have an option controlling this behavior and I'm sorry for disappointing you on this issue."

I am very impressed with your apology; it shows humility, which is a wonderful quality.

However, I also agree with the postings that follow yours, starting with "an option to disable a feature that doesn't work IS a bug, not a feature request."

There are many situations where the current autoindenting simply doesn't work right, and a simple CRLF is what we want Enter to represent. Even if you yourself love autoindenting, and even if it were true that it works right (which it doesn't, as documented in this thread), you really have to respect these many bug reports that indicate that lots of people want to turn off autoindentation.

How many years do users have to struggle to get a user option fixed in Open Source Microsoft land? This is not how I have ever worked on software in my 40 years as a software engineer. I appreciate your wonderful apology, but a fix would be so much more useful and satisfying. I would be able to use VSC as my editor,

[aclarkxyz]

This thread has captured several distinct problems... The current implementation for handling Enter in the editor is a bit complex and influenced by quite a number of things:
...

Could it perhaps be easier to just add another top level configuration flag with a name like "Preserve same indent for new line", which would do what cutting edge IDEs from the '80s and '90s did: just keep the same indentation as the line immediately before it.

The substance of this thread is that this trivial-to-implement solution is actually a nice middle ground that a lot of people like, and has been removed from too many modern IDEs. Having no autoindenting at all (i.e. going back to column 1) is not appealing to most people... but making a prediction about what should happen is problematic for a number of reasons, and a lot of people (including me) don't want that.

BTW, generally speaking, great work: I enjoy using this IDE much more than anything else that's going on right now.

[alexdima]

@David263 I appreciate your feedback, and yes, I am honestly apologizing.

---

Here is what happened in this specific case with this issue:

1. It came in
2. It got classified as a feature request
3. I unsubscribed
4. Nobody from the VS Code team has been subscribed to the issue and the issue has not entered top 100, so nobody from the VS Code team has read the comments that you have been writing for the past 3 years until today.
5. I read these comments today thanks to an email from the community that came our way raising the issue.
6. I try to put out a fire that I didn't know was burning, so I am sorry about that.

---

Here are tools available to you (as part of the community) to bring things to our attention instead of getting frustrated that we are not answering. But we are not answering because maybe we are not subscribed to issues, so we don't get notified when you write a comment in a feature request that is not assigned:

1. (preferable) mention people. Pick anyone from the VS Code team and mention them like this in your comment -- e.g. @alexandrudima. This will immediately subscribe the person you are mentioning to the thread and make a new notification for them.
2. create a new issue. Yes, it might appear counter intuitive, but a new issue will be looked at quite quickly, while a triaged feature request, even one with 40 upvotes might not be looked at in potentially a long time.
3. send emails (like it happened in this case).
4. ping via twitter @code

---

If you wouldn't mind, at this point, I would like to apologize one final time and to kindly ask that we end the meta-discussion and focus again on the reported issue around Enter.

[David263]

aclarkxyz, I like your suggestion because of its predictability, but I'm unclear as to whether you are opposed to having a setting that would make the Enter key simply generate a newline, with no indenting at all. In my opinion, indenting "automatically" is a very hard AI problem that will likely never be solved. There will always be cases where we want the line after an indented line not to be indented, whether in plain text or in source code.

[aclarkxyz]

aclarkxyz, I like your suggestion because of its predictability, but I'm unclear as to whether you are opposed to having a setting that would make the Enter key simply generate a newline, with no indenting at all. In my opinion, indenting "automatically" is a very hard AI problem that will likely never be solved. There will always be cases where we want the line after an indented line not to be indented, whether in plain text or in source code.

No reason to be opposed to it at all as long as it's opt-in. I suspect that it's the least popular of the 3 options, but there isn't really a case for denying it. Obviously a lot of people are fine with predictive autoindenting, otherwise it would not have survived becoming the only option for so many IDEs. The thing I want is simple autoindenting, which is probably the 2nd most popular option. And then no autoindenting for people who just want nothing to do with it...

[geekley]

The current implementation for handling Enter in the editor is a bit complex
The challenge is to come up with an editor option which would allow turning on/off the 4 "plugins" individually.

So it seems to me that this would be solved with a configuration (which could also be overriden as language-specific) that would apply with precedence over all other logic, like:
"editor.newLineIndentation": "none" | "repeat" | "smart"
Where "smart" would be the default and current behavior; "repeat" always repeats the indentation from previous line; "none" goes back to column 1.

What I mean is: maybe having a 5th "override" logic is easier to do than changing all other 4.

I'm assuming this setting shouldn't apply to pasting text as well, just to enter key.

[alexdima]

I really like your suggestions, here is what I am planning to do:

editor.autoIndent will change to be "none" | "keep" | "brackets" | "advanced" | "full", so you can think of it like a "slider" becoming more and more opinionated. The explanations are:

• "none": Pressing Enter will insert \n and nothing more.
• "keep": Pressing Enter will keep the indentation of the current line.
• "brackets": "keep" + the special logic around brackets {|, {|} etc.
• "advanced": "brackets" + respecting onEnterRules
• "full": "advanced" + respecting indentationRules

This setting will be respected in multiple places:

• when pressing Enter
• when pressing Tab
• when indenting/unindenting lines

In order to not break anyone, the auto-migration will be:

• "editor.autoIndent": false => "editor.autoIndent": "advanced"
• (default) "editor.autoIndent": true => "editor.autoIndent": "full"

[David263]

@alexandrudima Wow! Wonderful. VSC will have the best autoindenting options of any editor. I can't wait to return to VSC.

[nate-owens]

@alexandrudima I absolutely love this solution! Thanks for prioritizing it.

And thanks to whomever sent that email! ;)