Pressing u will undo all the stack.

[yacinehmito]

• 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.

---

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
This is a bug report

Environment:

• VSCode Version: 1.15.1
• VsCodeVim Version: 0.10.0
• OS: macos 10.12.6

What happened:

I press uin Normal mode in an editor window. Every single action in the undo stack was undone. Here's a GIF:

What did you expect to happen:

I expected the last action on the stack to be undone.

How to reproduce it:

I have no idea. I was reliably triggering the bug with the exact buffer I had but at some point it stopped doing it. Then it did it again.

[yacinehmito]

And now it's doing it again in another project. When I reloaded the project the bug stopped.

The only similarity between the two instances of the bug is that it happened both times on an HTML-like file (first time on a vue file; second time on a proper html file).

This is the list of the extensions that I have installed and their versions:

• Auto Close Tag 0.4.3
• Auto Rename Tag 0.0.14
• Code Runner 0.7.1
• Debugger for Chrome 3.2.1
• EditorConfig 0.10.1
• ESLint 1.2.11
• Git History (git log) 0.2.3
• Git Lens 4.4.3
• HTML Snippets 0.1.0
• JavaScript (ES6) code snippets 1.4.1
• Nix 1.0.1
• npm 0.2.1
• npm Intellisense 1.3.0
• Path Intellisense 1.4.2
• Search node_modules 1.1.1
• stylelint 0.29.0
• Vetur 0.9.7
• Vim 0.10.0
• vscode-icons 7.12.0

[ryanpag3]

Having same issue

Extension List

• Beautify css/sass/scss/less 1.7.2
• Color Picker 0.4.5
• HTML CSS support 0.1.8
• HTML Snippets 0.1.0
• IntelliSense for CSS class names 1.10.0
• Javascript ES6 Code Snippets 1.4.1
• Live Server 2.1.1
• Node.js Modules IntelliSense 1.4.0
• npm 0.2.1
• npm IntelliSense 1.3.0
• TODO highlight 0.5.11
• Vim 0.10.0

[Chillee]

Putting this inside vim.otherModesKeyBindings is a good temporary fix if this is a big issue for you:

        {
            "before": [
                "u"
            ],
            "after": [],
            "commands": [
                {
                    "command": "undo"
                }
            ]
        },
        {
            "before": [
                "<C-r>"
            ],
            "after": [],
            "commands": [
                {
                    "command": "redo"
                }
            ]
        }

[petejkim]

@Chillee
I think you meant to say

"before": [
  "<C-r>"
],

for the redo.

[Chillee]

@petejkim You're correct! Thanks!

[drice]

Terrible, confusing behavior. I cannot tell what has been undone, more times than not it's too much. Please make it VIM-like

Thanks @Chillee for the fix. This is better than the default behavior, too much is better than too little. Is there a way to have this undo block edits, etc?

[Chillee]

@tbsf We try, but unluckily bug-free software is hard to write :(

I don't believe so. Not without a significant amount of work.

[xconverge]

Is anyone here NOT using enableNeovim? Just want to rule that out...

[drice]

vim.enableNeovim is set to false for me

[xconverge]

Great thanks, just wanted to make sure

[xconverge]

Next time this happens to someone, can you check to see if you have the same file open twice in vscode please, then either thumbs up this for yes, or thumbs down it for no

[justinaray]

I can confirm this bug as well:

Runtime:

• VSCode: 1.15.1
• Mac 10.12.6

Extensions:

• Editor Config: 0.10.1
• Prettier: 0.21.1
• ESLint: 1.3.2
• Vim: 0.10.1

Only custom vim settings are:

"vim.disableAnnoyingNeovimMessage": true,
"vim.useSystemClipboard": true,

I did not have two copies of the file open (voted above)

[cecton]

I had the issue too and the temporary fix with the keyBindings seems to help. It's a very disturbing behavior to me as ViM is my main editor. I basically did the clicks to undo stuff for a while because of that bug...

[cecton]

No actually the temporary fix of @Chillee is still not the behavior of ViM. If you are in insert mode and remove character with backspace, go to normal mode and press u, every character will be undo one by one.

[jakkan]

I also have this bug. I am disabling this plugin for now. Looking forward to a fix.

I press u and all characters in the document are deleted one by one.

[jcjolley]

FWIW, I also am experiencing this bug. Hitting undo is like rolling the dice.

[Chillee]

@cecton Yes, unluckily it's a temporary fix that's not very good. It's why we haven't rolled it out as a default.

[cecton]

@Chillee still you and all the contributors are doing an amazing job with this plugin. Thanks 👍 I think Vi is a really complicate editor to emulate the behavior.

I use some times a "normal" editor on other's computer but I have grown so much with Vi that anything else feels cumbersome to use.

[dcolthorp]

I've been evangelizing VS Code at my office for the past few months for TypeScript work. Most of us use vim, and this fantastic plugin is key to VSCode being a viable option at all. Fantastic work!

However, this issue is a huge pain for many of us. I've paired with at least 5 people who have run into this issue and considered switching editors as a result. It is by far our number one pain point with VS Code. I've asked on our slack channel for others to upvote this issue, but I can say for certain that I know close to ten other people directly who feel pain from this issue.

Hopefully this issue is still on the radar.

[yegle]

This happened to me last night. It's very scary seeing your editor deleting lines that was not supposed to delete and you haven't add the file to VCS yet.

Please if possible prioritize this bug!

[bsaf]

Happy to help debug it – it might be a conflict with another extension?

[lmiller1990]

Just nuked like an hour of work in front of my eyes. I am very sad.

I have fresh VS Code with ESlint, Vetur, Vim, that's it. I only had one copy of the file open.

Version 1.19.1 (1.19.1)
OSX High Sierra

[yegle]

My installed plugins re #2007 (comment)

• AutoHotKey
• Bracket Pair Colorizer
• Go
• Vim

[yacinehmito]

@lmiller1990 If it happens to you again don't panic and just press ⌃R. Then ⌘⇧P and look for the Reload Window command. That should fix it.

[yacinehmito]

Given the information we have I think we can safely say that it is not caused by some conflict with another extension, but rather with how VSCodeVim handles the Undo stack.

Now that I've had this bug more times than I can count, in various situations, my guess would be that VSCodeVim identifies all the changes as a single action. The bug wouldn't be in the Undo itself but with the way the extension determines the boundary between two undoable actions.

[tctimmeh]

Just ran into this issue, lost 45 minutes of work. I clicked the 😕 but, honestly, this makes all of VSCode unusable, not just the plugin, because not having reliable vim keybindings in my editor is a deal breaker for me.

[Chillee]

I've still never run into this problem, but I'll commit to spending a chunk of time in a couple days either fixing this issue (hopefully), or at least implementing some kind of failsafe to prevent it from deleting so much work :(

[jonlaing]

I opened an issue on another plugin thinking the bug was there, but now reading this I'm starting to think it's here. This is the specific combination that seems to kick it off. Neither seem to cause the issue I'm seeing on their own.

• Vim 0.10.13
• Parinfer 0.6.1

Here's what happened. I was changing some user settings, then clicked over to a Clojure file. Parinfer asked me if I wanted to let it reformat the document (it needs to be formatted in a certain way for it to work) so I said yes. Everything seemed to be fine, then I started editing the file, made a mistake, hit ESC then u, and suddenly my whole file didn't just get nuked, but got replaced by my user settings file. I panicked and quit, but of course my VS Code autosaves on quit, so I nearly lost that file. Some state of it happened to still be in memory, so I was able to recover it, but it nearly gave me a heart attack.

I hadn't had any issues with the Vim port yet, so I figured it was Parinfer, and when I disabled it, the issue went away. Then I tried again today, and saw the same problem (committed my changes first so I wouldn't lose anything). This time it replaced it with my .gitignore. I'm pretty sure the only correlation there is that it was the first file I edited upon opening the app.

So, I opened an issue on Parinfer about it, but I'm also thinking it might be related to this issue as well.

[jkulskis]

I also just experienced this - almost didn't notice that I had deleted a couple hours of work. Redoing with Ctr+R and reloading the workspace to go back to normal undo behavior did the trick, but I'm not sure how to reproduce the bug.

[BigPictures]

This happened to me after using the Rename Symbol command. I'd expect any kind of refactoring that's done by VSCode as opposed to VSCodeVim to interact badly with VSCodeVim's undo stack.

[coreysharris]

FWIW, I have a very simple minimal example. You can do this in a new/existing buffer.

• Press 'A' to append to the end of the current line
• Type any character
• Press 'Esc' / CTRL-']' to leave insert mode
• Press '.' a few times to repeat the previous operation
• Press 'u'

The result is that everything will be undone.

[dcalhoun]

FWIW, I have a very simple minimal example. You can do this in a new/existing buffer.

• Press 'A' to append to the end of the current line
• Type any character
• Press 'Esc' / CTRL-']' to leave insert mode
• Press '.' a few times to repeat the previous operation
• Press 'u'

The result is that everything will be undone.

@coreysharris while I definitely experience this bug all the time, your reproduction steps don't actually recreate the issue for me. 😞

I'm wondering if there is some more global state that is causing this. Are you able to recreate the issue with your steps after you quit and start VSCode?

[coreysharris]

I disabled all other extensions and restarted VSCode. I can still reproduce by following the steps above.

Here's my version info:
Version: 1.49.2
Commit: e5e9e69aed6e1984f7499b7af85b3d05f9a6883a
Date: 2020-09-24T16:23:52.277Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Darwin x64 18.7.0

[J-Fields]

FWIW, I have a very simple minimal example. You can do this in a new/existing buffer.

• Press 'A' to append to the end of the current line
• Type any character
• Press 'Esc' / CTRL-']' to leave insert mode
• Press '.' a few times to repeat the previous operation
• Press 'u'

The result is that everything will be undone.

Unfortunately I'm unable to reproduce using these steps.

[kezabelle]

FWIW, those steps also don't reproduce it for me. Each . is undone by an execution of u (ie: ..... requires uuuuuu)

The only way I can make the above gif occur is by using the VSCode undo (ctrl-z/cmd-z) which does display that behaviour.
Given one of the proposed solutions somewhere upthread is to remap u to VSCode's undo (IIRC), @coreysharris is there a possibility you've done so?

[coreysharris]

Ah, yes I do have that workaround in my settings. Here's everything vim-related:

    // ViM settings
    "vim.normalModeKeyBindingsNonRecursive": [{
            "before": ["u"],
            "after": [],
            "commands": [{
                "command": "undo",
                "args": []
            }]
        },
        {
            "before": ["<C-r>"],
            "after": [],
            "commands": [{
                "command": "redo",
                "args": []
            }]
        }
    ],
    "vim.useSystemClipboard": true,
    "vim.easymotion": true,
    "vim.easymotionMarkerWidthPerChar": 12,
    "vim.easymotionMarkerFontFamily": "Fira Code",
    "vim.easymotionMarkerFontWeight": "normal",
    "vim.foldfix": true,
    "vim.leader": ",",
    "vim.sneak": true,

[joeytwiddle]

My two cents: I get this problem when I do multiple edits without leaving insert mode.

• If you enter insert mode, edit some text, exit insert mode, move, enter insert mode, edit some text, exit insert mode.

  Then this will be considered as two separate actions by the extension's undo.

• But if you enter insert mode, edit some text, then move with the mouse or the arrow keys, edit some text, exit insert mode.

  Then this is considered as one undo action. Oh no! Vim would consider this to be two actions.

This is what I experience, but others may be experiencing something else. I work mainly in JS/TS/MD files.

In this case, a possible solution might be to detect any movement in insert mode, and at that point mark a boundary/ending for the latest undo action.

(It is also worth noting that sometimes VSCode's native undo appears to group separate edits together, and sometimes it doesn't. I'm not sure why. I observed this when using VSCodeVim, not in default mode.)

[evelant]

There seem to be corner cases where this can cause you to irretrievably lose text. I haven't figured out the exact pattern yet but I think it's in combination with VSCode's native undo behavior. Being a vim newbie I sometimes still grab the mouse or enter non-vim keystrokes accidentally. When you do this it's possible to get into a situation where vscode-vim deletes some text from the buffer but afterward it isn't in either vscode or vscode-vim's undo stack. There's no way to get it back. That can be pretty disastrous depending on what and how much got removed. This is probably related to both this issue and the one about syncing undo stacks.

[norogoth]

Definitely looking forward to this issue. I had my files delete a LOT multiple times and just recently realized it is the u key going beserk. Thanks for all your work devs.

[Samuelfaure]

Same exact issue here, lots of text lost & extremely infuriating, but the shortcut provided vim.normalModeKeyBindingsNonRecursive seems to fix the issue.

Thanks to the team for your hard work.

[tekboart]

Added this code to my settings.json solved the problem. The above solution added at vim.otherModesKeyBindings does not work for me.

"vim.normalModeKeyBindingsNonRecursive": [
        {
            "before": [
                "u"
            ],
            "after": [],
            "commands": [
                {
                    "command": "undo"
                }
            ]
        },
        {
            "before": [
                "<C-r>"
            ],
            "after": [],
            "commands": [
                {
                    "command": "redo"
                }
            ]
        }
    ]

Thanks a lot @khanhhuy

Not only did it solved the recursive problem but also the problem of not being able to use "u" to undo inside jupyter notebooks.
Your solution saved the day for me.

yours,
tekboart

[J-Fields]

Not only did it solved the recursive problem but also the problem of not being able to use "u" to undo inside jupyter notebooks.

Note that this is a separate issue and will be fixed in upcoming release.

[autoferrit]

I have been having this problem again. Originally adding the bindings to "vim.normalModeKeyBindingsNonRecursive" worked for me but even having them in there, it happens. in this case, it was in a shell file like foo.sh

[Untersander]

Added this code to my settings.json solved the problem. The above solution added at vim.otherModesKeyBindings does not work for me.

"vim.normalModeKeyBindingsNonRecursive": [
        {
            "before": [
                "u"
            ],
            "after": [],
            "commands": [
                {
                    "command": "undo"
                }
            ]
        },
        {
            "before": [
                "<C-r>"
            ],
            "after": [],
            "commands": [
                {
                    "command": "redo"
                }
            ]
        }
    ]

Thanks a lot @khanhhuy

Not only did it solved the recursive problem but also the problem of not being able to use "u" to undo inside jupyter notebooks. Your solution saved the day for me.

yours, tekboart

This seems to fix my problem, wondering what the state is as there has not been any comments on this for over 1 year.

[eduarddejong]

Manually overriding the Ctrl+r and u by remapping these to VS Code undo and redo does obviously kind of "work".
But what I understand from issue #1490 is that the separation between 2 different histories is by-design.

And for good reasons as it turns out:
The normal undo/redo work quite differently from the Vim ones.
For example when I insert some text in insert mode and then finish with Escape, the Vim undo will undo that entire edit as 1 operation, while VS Code undo restores typed words and characters only one by one.
That's a pretty big trait-off, which I do not like to make, because I want actual Vim behaviour.

However in many cases, VSCodeVim currently seems to be pretty blind for many automated edits that VS Code does based on intellisense suggestions, a problem which causes these edits to be missed in VSCodeVim history.

So pressing u does not only undo that edit in such a case but your previous edit as well.
And that results in a lot of frustration, followed by stressed out tapping on the Ctrl+z several times until the intended restore point has been reached from VS Code's normal history.

So I really think there is an actual problem that needs to be solved, not just a key remapping to the normal undo/redo.
Maybe the fix exists already, and I am having some problematic configuration? But in that case I do not directly understand what it could be.

[willtalmadge]

I hope this can get fixed someday, I switched from vscode to DataSpell for ML development as their vim mode is integrated into the editor and never has problems with undo. But, I understand this is a complex issue to fix, potentially intractable without support from MS to harmonize the histories somehow.

[yacinehmito]

FYI This specific bug hasn't happened to me for quite some time (at least a year? two maybe?). I still have issues with undo but it's not this one.

I am considering closing the issue but apparently some people still experience it. @eduarddejong @willtalmadge Do you confirm?

[bertachini]

@yacinehmito I experienced this problem for the first time today.
I'm running vscode with vscodevim (1.27.2) and pressing U suddenly undid hours of work.

[ohir]

@yacinehmito
It happens for me "since always" with Go, Dart, Perl. Not that much often recently, but if it hops out of bushes it bites hard.
I several times tried to get some stable repro case but to no avail.
Is there some method to log all edits and undos? I would work with such log on to help pinpoint this heisenbug at last.
Thanks!

[nfairfield]

I keep getting running into this issue, but it seems random. Today I found one very reproducible pattern.

1. Create a new text file
2. Type the following text <html>I like vim.</html> as a single insert session, then hit escape
3. Right click, and select "Format document". it should now look like

<html>I like vim

</html>

4. Move up to the second (blank) line and insert "a lot!".

<html>I like vim
a lot!
</html>

6. Then hit escape, then hit 'u' to undo.

Expected:

<html>I like vim

</html>

Actual:
<html>I like viml>
which is just... weird! It's as if the format and the edit got shuffled together, which is definitely what it feels like when this bug bites me elsewhere.

Oddly, if I make typos, have to hit delete, etc, while entering the original insert... it changes the final result!?! Again, probably due to the "shuffling"?

vscodevim v1.28.0
vscode
Version: 1.92.2 (user setup)
Commit: fee1edb8d6d72a0ddff41e5f71a671c23ed924b9
Date: 2024-08-14T17:29:30.058Z
Electron: 30.1.2
ElectronBuildId: 9870757
Chromium: 124.0.6367.243
Node.js: 20.14.0
V8: 12.4.254.20-electron.0
OS: Windows_NT x64 10.0.22631

[ivnsch]

Also have this issue, Mac M1, last vscode version.. neovim not installed.

Q: is neovim still an improvement? there were some recommendations starting the thread, but that's from 2017.