Vim: Pressing <tab> still inserts the string "<tab>" sometimes

[haf]

[Zyst]

Yep, have the same issue.

Happens a handful of times a day to me, it's not a dealbreaker but it is annoying as hell.

OS X: 10.12.2
VSCode: 1.8.1

Every Vim setting is default other than:

    /**
     * Vim variables
     */
  "vim.useSystemClipboard": true,
  // Make jk exit insert mode
  "vim.insertModeKeyBindings": [
    {
      "before": [
        "j",
        "k"
      ],
      "after": [
        "<Esc>"
      ]
    }
  ],

[Zyst]

I dunno what triggers it, but it's becoming worse.

Now it inserts the "" character until I restart VS Code. I think you never realize how much you use "tab" until something like this happens.

[johnfn]

This is unfortunately due to an unavoidable race condition due to a lack of information sent back from VSCode. I wrote a little explanation here: https://github.com/VSCodeVim/Vim/issues/875#issuecomment-252826237

I don't think it's unsolvable, but it is annoying to fix.

[johnfn]

It's weird that this issue is gaining more thumbs up, because after I made a fix a few weeks back, I practically never encounter it (less than once every other week of all day coding, I'd say).

If anyone thumbsing-up this issue could either provide

• Reproduction steps
• Or failing that, your settings.json file

it would be greatly appreciated!

[Zyst]

I'll share reproduction steps if I run into something that is reliably reproduce-able.

Most of the time it seems random, but the occurrence has definitely lowered.

[nimarb]

I can't really reproduce it reliably, but it happens extremely often for me. When I have been typing for 2/3mins without mode change it will definitly happen (on Arch Linux and Windows, latest everything).

Furthermore, when in the insert mode, the END, POS1 and DELETE keys won't work anymore until I have pressed escape, and then go back into insert mode, which is extremely annoying.

I think I'll switch back to the VScode version from mid december which did not have that problem..

[johnfn]

@likyng are you saying that you stay in insert mode for a long time, and then you begin to see the tab character more?

[pitkane]

Same here, happens often when insert mode is "left on" in certain file, and after surfing through other files and coming back to that origin file thing happens. Very hard to reproduce reliably, sorry :( MacOS 10.12.2, Code 1.8.1, Vim 0.4.10 (latest)

Edit: I think I found out how to reproduce this: https://cl.ly/imc0 (mov)
In file 1, switch to insert mode, go to file 2 and switch back and forth between normal and insert mode (dunno if multiple switches is necessary), go back to file 1 and press tab. I'll try to restart Code now and see what happens ->

Edit 2: After restart I can still reproduce it. Leave file 1 in insert mode, in file 2 normal mode -> insert -> normal, back to file 1 and press tab = <tab> appears.

settings.json

{
    "editor.fontFamily": "Source Code Pro, Menlo, Monaco, 'Courier New', monospace",
    "editor.fontSize": 15,
    "editor.cursorStyle": "block",
    "editor.renderIndentGuides": true,
    "editor.renderWhitespace": false,
    "window.zoomLevel": 0,
    "editor.cursorBlinking": "blink",
    "editor.tabSize": 4,
}

[matwood]

I used the split editor, followed the steps listed by @pitkane and also was able to reliably reproduce the issue.

1. Open a split editor.
2. Make sure both editors are in normal mode and looking at 2 different files (Untitled-1 and Untitled-2).
3. Turn on insert mode for one split editor (Untitled-2).
4. Go to the other split (Untitled-1) and turn on insert mode and turn it back off.
5. Go back to the original split (Untitled-2) and hit tab.

[okoriko]

@johnfn similarly to what @matwood / @pitkane described (step 1-3 are the same), I can reliably reproduce it with:

1. Open a split editor.
2. Make sure both editors are in normal mode and looking at 2 different files (Untitled-1 and Untitled-2).
3. Turn on insert mode for one split editor (Untitled-2).
4. Click to set the caret position elsewhere on the same document (Untitled-2).
5. Hit tab and the characters <tab> will be written.

Notes:

• I couldn't reproduce it without splitting the editor.
• Getting out of insert mode and back again fixes the issue.
• I am using version 0.4.10 on vscode 1.8.1 (ubuntu 14.04).

[johnfn]

Wow, thank you both for the phenomenal reproduce steps! I see the problem is that there were actually two different ways that <tab> could be inserted, but I had only fixed one of them. This will make things much easier. Thank you!

(I also see the reason I never trigger this is I never leave a panel in anything but normal mode.)

[johnfn]

Fixed and because I realize this was driving a lot of you nuts I immediately pushed out 0.4.11 with this fix.

Thanks again!

[okoriko]

@johnfn thank you!

[godbout]

Still having the issue here, happening very, very often. Usually after I run some tests in the integrated terminal, or when I format the current document. Any way to help point out where might be the issue?

[jpoon]

Fixed https://github.com/VSCodeVim/Vim/pull/2320. At an airport right now, will push a release when I get better wifi.

[godbout]

Airports. The best place to be creative 😍️😂️

Thank you!

[jpoon]

@Chillee Moving the discussion here (https://github.com/VSCodeVim/Vim/issues/831#issuecomment-362878696) as we closed that issue as a dupe.

Do we care about <tab> in a widget? https://github.com/VSCodeVim/Vim/blob/master/package.json#L126, should it be editorTextFocus?

[Chillee]

@jpoon whups. We don't, and I don't think the issue of whether we capture tabs or not in tabs is really related.

I'm pretty sure the issue is that we're setting the context vim.mode at multiple different places, and it's possible for the <tab> to be captured because vim.mode is in normal mode, when we're really in insert mode.

[Chillee]

@jpoon Huh. Removing the await here: https://github.com/VSCodeVim/Vim/blob/68e793fb25254e14bbb4823ccc28dd500af8feb0/src/mode/modeHandler.ts#L1350

not only seems to solve the <tab> case for the repro I posted above, it also seems to provide performance improvements as well.

[jpoon]

Funny, I was thinking of doing that exact same change and reviewing our overall usage of await. Great to hear that it's better. But I wonder if that'll expose timing issues.