Auto indentation rules

[csholmq]

With the new editor.autoIndent option, language extension authors can provide indentation rules.

As this is the main extension for C/C++ language development, perhaps a few rules could be included?

https://code.visualstudio.com/updates/v1_14#_auto-indent-on-type-move-lines-and-paste

[sean-mcmanus]

Thanks for letting us know about this. Another user also recently requested autoIndent for one-line if/while/etc. statements that don't start with {.

[csholmq]

You're very welcome! So many new features coming out it's hard to keep track.

With the built in support in VSCode, I'm hoping it would be a minor task for you guys to write up some rules. You ciuld probably knick some from another extension, e.g Java.

[sean-mcmanus]

One user is getting the behavior you want, but we don't have a repro: #887 . In the Allman style, the { goes on a new line so the indentation is not desired on Enter, unless typing { can undo the indent.

[csholmq]

Yes. Well basically don't indent if a curly brace is involved.

[rebornix]

@sean-mcmanus for your information, VSCode indentation rules follow TextMate so to make this happen, you can

• Follow TextMate documentation https://manual.macromates.com/en/appendix
• Build on top of existing community indentation rules (Atom) and make enhancements.

Let me know if you run into any problem while adopting this feature.

[shunyaoshih]

I need an autoIndent for one-line if/while/for, too. Look forward to this feature!
Maybe VS Code could provide developers with "indentNextLinePattern" which is included in TextMate. With this indentation rule, I think it will be much easier to implement this feature.

[antcodd]

The reindent lines feature seems to seriously mangle block comments. The indentation rules should probably preserve the indent withing block comments, doubly so if the lines are preceeded by *?

e.g.

/*
 * Foo
 */

becomes

/*
* Foo
*/

[sean-mcmanus]

@antcodd What reindent lines feature are you talking about? Does it repro without the cpptools extension installed? Are you doing a format?

[antcodd]

@sean-mcmanus The Reindent Lines command introduces in VSCode 1.9, which I believe uses the same language indent rules as the original link in this issue. This is distinct from the Format Document feature, although I think at one point one was falling back to the other (not sure which way around). See also the discussion in microsoft/vscode#28658 and microsoft/vscode#19847

It looks like there is a already a bug for this comment whitespace issue, at least for TypeScript: microsoft/vscode#19142.
Even more problematically it also reformats single line if blocks, which may be the same issue mentioned there by @rebornix.

if (foo)
    dosomething();

to

if (foo)
dosomething()

To be honest I'm not quite sure where this discussion fits, is there an issue tracker for language-c in VSCode? I suspect the Atom folks will be reluctant to work around issues in VSCode.

Basically, I got burned by a number of issues with Reindent Lines (not operating on the selection only, adding trimmed whitespace and messing with comments/if) combined with VSCode not showing whitespace changes in the git gutter. I'm having to carefully revert some unstaged changes because of this.

[sean-mcmanus]

@antcodd The atom/language-c issues page is https://github.com/atom/language-c/issues , but I'm not sure if this is an atom/language-c issue.

[bobbrow]

VS Code currently sets the rules for indentation. We haven't implemented any custom rules (we need to, but haven't had the time) and I've actually turned off the new VS Code indentation ("editor.autoIndent": false) as of recent builds because lately it seems to be wrong more often than not - especially when pasting code. I believe they just recently switched the default from "false" to "true" and turned it on for everyone.

[bobbrow]

I'll correct myself. The rules do, in fact, come from atom/language-c. VS Code reformatted them, so I didn't notice at first.

[csholmq]

I thought I'd give a stab at this. But should I add it to the extension or append the VSCode formatting rules instead?
If I add it to the extension I have to duplicate the existing VS Code rules as the extension will override the default language_configuration.json file.

[sean-mcmanus]

It looks like you tried to add the change to VS Code itself, which seems fine, but if a correct implementation can't be done with the regex then maybe we'd have to use our lexer code to get correct behavior, but I'm not sure if the VS Code language protocol has a way for us to implement this.

[csholmq]

Right. That was sort of my conclusion starting to look into this. I also commented that in microsoft/vscode#36148

@rebornix This seems almost impossible to fix using regex rules. Would using IntelliSense with direct knowledge of scope be more feasible?

[qraynaud]

This is also somewhat related to one of the issue I opened (microsoft/vscode#46401) in the sense that maybe what I'm suggesting would remote the need for certain rules.

[manassingh2611]

I want you to add a feature to escape formatting for a line or a block of text to get results like this:
krijgertje's solution
Some code is better understood when written in one line.
What I suggest is a quick key combination like CTRL + / which comments a line when no text is selected or comments an entire selection when text is previously selected.

Maybe when the formatting parser runs upon Save, the lines with a flag of 'don't format' are simply skipped. The flags are added by the user while writing code with a key combination for e.g. CTRL + >, which would be indeed very similar in working to the commenting mechanism.

[J-Fields]

As I explain here, VSCodeVim relies on indentationRules to correctly handle commands such as cc (change line). Implementing this would be a huge help!

[bobbrow]

linking this to #657. We may do both of these together when we get the VS formatting engine integrated.

[manassingh2611]

I have been using vim for a few months now and there is an amazing plugin called vim-clang-format which can be used on selected text in VISUAL mode. I was hoping for something just like that when I created an issue here

[kevinushey]

One of the main things I'd like to see is vertical alignment of arguments when defining a function. For example, in this case:

I'd like to see the cursor indented to align on int a.

[bobbrow]

We added support for the Visual C++ formatter in the 1.0 release. You can achieve this with the following settings:

"C_Cpp.formatting": "vcFormat",
"C_Cpp.vcFormat.indent.withinParentheses": "alignToParenthesis",
"editor.formatOnType": true

[bobbrow]

clang-format is capable of doing this too, just not as you type. You have to invoke the "Format Document" command.

[kevinushey]

Thanks! Unfortunately, the experience here is a bit janky for me -- there's a substantial pause between the time when I insert a newline, and when indentation is applied. It seems like sometimes the indentation attempt just ... times out? It's worth saying that I'm editing a file with a substantial number of large header includes (e.g. Boost); not sure if that effects things here.

If I'm typing quickly, then no attempt at indentation happens at all (and also notice a rogue right parenthesis gets duplicated; normally ) insertion would just move over the already-inserted paren):

All that said -- rather than a "smart-enough post-hoc indentation system", I'm really hoping that cpptools could just immediately place the cursor in the "right" place after a newline is inserted. (I imagine this is incredibly challenging to solve in general due to the complexity of the C++ grammar, but I think at least in this case it should be easy?)

It seems like a lot of C++ developers using VSCode are used to this workflow (write code without as-you-type indentation, and then format afterwords using an appropriate formatter) but coming from other editing environments (e.g. Vim) I'm used to seeing the cursor just "be in the right place" with newline indentation.

[bobbrow]

Hmm... The formatter shouldn't care about included files, so using boost shouldn't affect this at all. I'm going to copy your comment over into a new issue and we can look into what's going on.

[github-actions]

This feature request has received enough votes to be added to our backlog.