Vim: autoindent with == doesn't work as expected

[martinwk]

• Click thumbs-up 👍 on this issue if you want it!
• Click confused 😕 on this issue if not having it makes VSCodeVim unusable.

The VSCodeVim team prioritizes issues based on reaction count.

---

What did you do?

When I have this code in Python:

def someFunction(arg1):


print('this should indent') 

And when in normal mode with my cursor on the line print('this should indent') and press ==

What did you expect to happen?

Indent of four spaces

What happened instead?

Nothing

Technical details:

• VSCode Version: 1.11.2
• VsCodeVim Version: 0.6.18
• OS: windows

[suan]

I just noticed this too with Ruby! And I believe it was working just a week or two ago - seems like a regression

[johnfn]

Would you guys mind testing to see if this isn't a regression with VSCode itself e.g. that using VSCode's command palette to indent the line continues to work appropriately?

[mikew]

Using the command palette to Reindent lines doesn't indent the line for me in VSCode 1.11.2, with "donjayamanne.python" and "magicstack.magicpython"

[johnfn]

If you guys find that to be the case, I'd encourage you to post a bug on the VSCode repo. 😄

[martinwk]

I did not have time to check this myself. If I find the same I will definitely file a bug report there.

[xiaogwu]

Reindent lines in VSCode seems to still work. So yeh, == is definitely not behaving as expected..

[Chillee]

@xiaogwu So there's actually 2 commands relevant to this. One is the reformat command and one is the reindent lines. The re-indent lines doesn't let us choose a range, so we have to use reformat for now.

[oswaldoferreira]

Here's my workaround for now (this goes into vscode config):

    "vim.otherModesKeyBindingsNonRecursive": [
        {
            "before": [
                "="
            ],
            "after": [],
            "commands": [
                {
                    "command": "editor.action.reindentlines",
                    "args": []
                }
            ]
        }
    ]

[Chillee]

@oswaldoferreira The difference is that reindentlines reindents the whole file, while = operates over a range.

[oswaldoferreira]

@Chillee Was about to edit the comment when noticed that! :/

[xvjiarui]

have the same issue with vue, it prompts that Sorry, but there is no formatter for 'vue'-files installed.

[SamuelTissot]

I also have the issue that @xvjiarui describe Sorry, but there is no formatter for 'go'-files installed.

NOTE

• the gofmt command line works
• vscode editor.action.formatDocument works a expected

the issue is when I use = to format the code. I have tried to set the value of go.formatTool to gfmt, goreturns but still I get the notice "Sorry, but there is no formatter for 'go'-files installed."

I have disabled all other extension and re-installed vscodevim, without any results.

thanks

[adamlounds]

@SamuelTissot I have the same problem, but using vscode's built-in selection formatting (⌘K ⌘F) has the same result, so I don't think it's a vim plugin issue. I can format the whole file with ⇧⌥F or on :w save, so I'm using that as a workaround for now.

[Chillee]

Doesn't work the same since it indents the entire file.

[eric-burel]

Hi,
This issue appears with Vetur too, as pointed out by @xvjiarui , see this thread.

What is the default action bind to = ? reindentLines ? Some languages/format/libs would expect it to call formatDocument instead, so we need to remap the = manually. I noticed this after an update to VSCode 1.9, I did not encounter this issue before. After the remap I did not have much trouble, though it sounds more like a quickfix than an actual solution.

[octref]

The problem is there are two types of formatters in VS Code:

• selection formatter (format the selected part)
• document formatter (format the whole document)

When extensions only have document formatter, and you try to format a selection (such as Vue and Go), the message no formatter for x file found shows up. I have opened up an issue on VS Code side to provide a more meaningful message.

[vegerot]

Hey, so it's nearly 2020 right now and I'm just wondering if there's been any progress on this front? The problem is that typing == should have the same behavior as Indent Line does. Yet == doesn't seem to do anything. @oswaldoferreira 's workaround kinda works, but doesn't attempt to emulate vim's behavior at all

[J-Fields]

@vegerot I assume you mean it should behave the same as Reindent selected lines. We use Format selection, which handles many more scenarios. You're free to remap it to the former yourself, but I don't see how leveraging VSCode's formatting is the wrong approach.

[madchap]

So what is the actual solution here? As of today, I have the issue as well.

[J-Fields]

If you'd like == to act like Reindent selected lines, you can map it to that command

[madchap]

@J-Fields You're thinking exactly as posted in https://github.com/VSCodeVim/Vim/issues/1574#issuecomment-336285616 ? Or something different?

It might be helpful to post a definite solution on this thread.

[madchap]

The command that relates to the aforementioned one should now be:

"vim.normalModeKeyBindingsNonRecursive": [
        {
            "before": [
                "="
            ],
            "after": [""],
            "commands": [
                {
                    "command": "editor.action.reindentlines",
                    "args": []
                }
            ]
        }
    ]

but it's not working for me :-(

Does not work on python or bash (conflicting things?), and for the settings.json actually, it does not consider selected lines, but seems to do the whole block (as some others have mentioned, so no progress there I guess).

[J-Fields]

@madchap you can try editor.action.reindentselectedlines, but there's no good solution to this on our end. Formatting is done by each language's extension, and we just invoke the commands. https://github.com/VSCodeVim/Vim/issues/1017#issuecomment-569801348 is relevant.

[albheim]

@vegerot I assume you mean it should behave the same as Reindent selected lines. We use Format selection, which handles many more scenarios. You're free to remap it to the former yourself, but I don't see how leveraging VSCode's formatting is the wrong approach.

But is == really supposed to format? The default behavior in vim seems to be to reindent current line from what I can find, might be wrong though.

[jolars]

I agree with @albheim. If the behavior is to mimic vim, = should really mean reindent, not reformat.

[berknam]

From the VIM documentation:

={motion}               Filter {motion} lines through the external program
                        given with the 'equalprg' option.  When the 'equalprg'
                        option is empty (this is the default), use the
                        internal formatting function C-indenting and
                        'lisp'.  But when 'indentexpr' is not empty, it will
                        be used instead indent-expression.  When Vim was
                        compiled without internal formatting then the "indent"
                        program is used as a last resort.

                                                        ==
==                      Filter [count] lines like with ={motion}.

So it uses the internal formatting by default with the "indent" program being used as a last resort. So in this case by internal formatting we can consider the vscode formatting as being just that and it will apply differently according to which language is being used.

[jolars]

From the VIM documentation:

={motion}               Filter {motion} lines through the external program
                        given with the 'equalprg' option.  When the 'equalprg'
                        option is empty (this is the default), use the
                        internal formatting function C-indenting and
                        'lisp'.  But when 'indentexpr' is not empty, it will
                        be used instead indent-expression.  When Vim was
                        compiled without internal formatting then the "indent"
                        program is used as a last resort.

                                                        ==
==                      Filter [count] lines like with ={motion}.

So it uses the internal formatting by default with the "indent" program being used as a last resort. So in this case by internal formatting we can consider the vscode formatting as being just that and it will apply differently according to which language is being used.

Okay, you're right that it does seem to be intended to be customizable depending on what language is used, but I would argue that the intention of the command is only to do indentation.

The "internal formatting" here, for instance, refers to the 'lisp', 'cindent' or 'indentexpr' programs (https://vimhelp.org/options.txt.html#%27equalprg%27), which, unless I am mistaken, accomplish indentation and nothing else. indentexpr also explicitly states that the command shouldn't alter text (https://vimhelp.org/options.txt.html#%27indentexpr%27).

The different language formatters that are out there for VS code applies all kinds of formatting, which at least to me is a not what I would expect when using =.

[J-Fields]

Hmm, I think you're right that = technically should only reindent. Most people want full formatting in the age of prettier, etc., though, so how would they accomplish that? gq is probably right, but then we lose the ability to reflow text. @albheim @jolars any suggestions?

[jolars]

Maybe just making it a setting would be sufficient in this case? "vim.formatoneq": true. I would of course vote for the default to be false here, but at least it's nice to have a setting and not have to customize key mappings to get this behavior.

A completely different idea is to emulate https://github.com/Chiel92/vim-autoformat.

[albheim]

My comment came from having some problems with indentation that seems to stem from vscodevim using format and julia-vscode not doing indentation on format for some reason (but supporting the reindent lines command). So I would probably also be happy enough if julia-vscode fixed it on their end.

But a setting seems like a reasonable way to solve this, just be able to easily select if = should use the reindent or format as backend.