search

VSCodeVim / Vim

:star: Vim for Visual Studio Code
http://aka.ms/vscodevim
MIT License
13.96k stars 1.32k forks source link

Pressing `u` will undo all the stack. #2007

Open yacinehmito opened 7 years ago

yacinehmito commented 7 years ago

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:

What happened:

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

bug vscode

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 commented 7 years ago

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:

ryanpag3 commented 7 years ago

Having same issue

Extension List

Chillee commented 7 years ago

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 commented 7 years ago

@Chillee I think you meant to say 

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

for the redo.

Chillee commented 7 years ago

@petejkim You're correct! Thanks!

drice commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

drice commented 7 years ago

vim.enableNeovim is set to false for me

xconverge commented 7 years ago

Great thanks, just wanted to make sure

xconverge commented 7 years ago

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 commented 7 years ago

I can confirm this bug as well:

Runtime:

Extensions:

Only custom vim settings are:

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

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

cecton commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

Chillee commented 7 years ago

@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 commented 7 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

lmiller1990 commented 6 years ago

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 commented 6 years ago

My installed plugins re https://github.com/VSCodeVim/Vim/issues/2007#issuecomment-353399493

yacinehmito commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.

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.

smerrill commented 6 years ago

Thanks for the work on this plugin! I love VS Code and this plugin makes it supremely useful for me.

I've had a similar problem in the last few days where the contents of a file I was editing were replaced, character by character, with a package.json file I had open in the same project when I typed u.

KarboniteKream commented 6 years ago

This issue happened twice to me today, similar to @smerrill

Chillee commented 6 years ago

@jonlaing Does it happen consistently when you're using parinfer?

dcolthorp commented 6 years ago

@Chillee We've seen this happen without parinfer. It seems to like Vim gets confused about which buffer the undo history belongs to. It may be related to other plugins modifying the buffer. We use Prettier heavily with format on save enabled.

I've experienced both, but couldn't tell if this issue is related to the large numbers of changes getting lumped together which I'd spoken up on this thread about – they feel different in the moment, though I certainly wouldn't know if they share a root cause.

jonlaing commented 6 years ago

@Chillee I was having a hard time reliably reproducing, but I'm pretty sure the first issue I saw got kicked off by Parinfer editing the buffer to format it. That said, I also noticed the same thing without Parinfer enabled just recently, so I'm pretty confident it's not Parinfer.

The most recent one I saw was with Parinfer disabled, and no formatting plugins that I know of. Just raw JS with ESLint. I have noticed some success with closing the affected file without saving and opening it again. I'm starting to get into the habit of pressing u before making any changes just to make sure it doesn't do the replacement after I've done a bunch of stuff.

jonlaing commented 6 years ago

It should also be noted that Cmd-Z does not trigger this behavior, only u.

smerrill commented 6 years ago

I also use Prettier format-on-save on at least some of the projects where this happens.

jonlaing commented 6 years ago

I used format-on-save with my ReasonML projects, but hadn't noticed it. That said I haven't worked on those for a month or two, so maybe this issue is new and related to a change in VS Code that broke Vim. Just speculating.

Chillee commented 6 years ago

I'm mainly just trying to look for some kind of reliable repro. Perhaps it has something to do with format on save, or more generally, some kind of interaction between VSCode triggered changes + undo?

yacinehmito commented 6 years ago

That said I haven't worked on those for a month or two, so maybe this issue is new and related to a change in VS Code that broke Vim.

This issue is from Sep 2017.

Perhaps it has something to do with format on save, or more generally, some kind of interaction between VSCode triggered changes + undo?

@Chillee It seems to be a good idea to investigate towards format-on-save. I've been working without format-on-save for a month and the issue didn't happen even once during that time. However I don't think the bug is related to the undo itself. I think it's the "action stack" that's problematic. What I mean by that is that VSCodeVim is probably seeing all the edits on the file as a single one.

Chillee commented 6 years ago

One more thing. Does it only occur when you guys've been working on a file for a while?

Also, do you guys have any remappings?

Chillee commented 6 years ago

Also, reading back through the thread, I'm starting to think that issue isn't actually that it's going through the undo stack, but that it's trying to go back to some previous state of the file (for w.e. reason).

Going back through the undo stack would mean that it's replaying the changes made to the file, just in reverse order.

What I suspect is happening is that it loads a history that thinks it's at some state A in the past, while the file is at some state B in the present. VSCodeVim notices that this new state B has a bunch of changes that weren't made previously, turns it into a sequence of additions/deletions, and stores them in as an undo action. Then, some unsuspecting soul presses u, causing the behavior we're seeing.

I tried playing around with a bunch of things on a single file (using ParInfer, which simultaneously modifies the file, using format on save + trying to overlap that with typing, some format on type stuff), and although I found some other buggy behavior, I didn't find any thing close to the behavior people are noting.

More importantly, I took a close look at the undo logic, and I don't think there's any way for it to blow through the undo stack. (famous last words...)

steinso commented 6 years ago

I have a remapping "vim.insertModeKeyBindings: {"before": ["j", "k"], "after": ["\<esc>"]}

I can let you know how I experience this; This is the common scenario: Edit some code, run the 'Format Document' function, edit some more code both insert and command mode, press 'u' - then I can see how it undoes my latest change ...and continues to undo all my recent changes, and it usually keeps going all the way back to before the "Format Document". I immediately press ctrl-r and sometimes I think it correctly plays back all the changes, but sometimes it definitely stops in a weird state. I can't remember how this happens.

Note: I can 'see' all the undos happening rapidly on my file.

kezabelle commented 6 years ago

I've had this happen, and it basically undid a whole file as if it were one action, and then CTRL-R didn't have a stack to fast-forward back to. I don't have parinfer or suchlike. I do not have any custom keymappings I do have:

"files.trimTrailingWhitespace": true,
"files.insertFinalNewline": true,
"vim.hlsearch": true,
"vim.startInInsertMode": true,
dcolthorp commented 6 years ago

I just experienced the variant of this issue where one buffer is replaced by another. You can see here that I'm looking at the contents of a graphql resolver file, and pressing u replaces the entire buffer line by line with a completely different file. The other file it was replaced with is the only other file I had open at the time.

vscode-undo

Chillee commented 6 years ago

@steinso @dcolthorp That makes it sound like there's 2 different issues here. One in which autoformatting screws up setting undo points, and another where the vimstate of a file gets replaced with another.

jonlaing commented 6 years ago

@Chillee I was speculating that they were the same issue, but if you think they're different issues, then the file replacement issue is the one I'm having.

KristofferC commented 6 years ago

Pressed u, my whole file was reverted to how it looked half an hour ago. No way to go back.

yacinehmito commented 6 years ago

@KristofferC Next time it happens, don't panic and just press ^R right away. Then restart VSCode to temporarily fix the bug.

KristofferC commented 6 years ago

Thanks for the tip. I really like this extension but being burned by this make it just too scary to use :(

jcjolley commented 6 years ago

I've yet to have it undo an entire file for me, but it has jumped back several operations before.

On Wed, Feb 7, 2018 at 3:38 AM Kristoffer Carlsson notifications@github.com wrote:

Thanks for the tip. I really like this extension but being burned by this it is just too scary to use :(

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/VSCodeVim/Vim/issues/2007#issuecomment-363728148, or mute the thread https://github.com/notifications/unsubscribe-auth/AB_VIIRWVdaxnEl301bx_O_ElWb6XA6dks5tSX0dgaJpZM4PO5xD .

cecton commented 6 years ago

⚠️ I think it's important to mention for the future readers and for the development team that the problem is not the same for everybody: on my side with the TypeScript extensions and a spell checker installed (and that's all, very simple) I've never experienced lost of data. I only complained about the inconsistency of the behavior with the real ViM.