search

VSCodeVim / Vim

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

Undo broken with new VS Code #8157

Closed marchbox closed 1 year ago

marchbox commented 1 year ago

Type: Bug

I just upgraded to VS Code 1.74.0 today, and started noticing an issue with undo command ("u") in Vim. It appears to only go back 2-3 iterations (my current Vim: History setting is "50"). And if I hit CTRL+Z, it first undoes what "u" just undid, then start actually undoing, e.g.

Here is my VS Code info: Version: 1.74.0 (Universal) Commit: 5235c6bb189b60b01b1f49062f4ffa42384f8c91 Date: 2022-12-05T16:43:37.594Z (2 days ago) Electron: 19.1.8 Chromium: 102.0.5005.167 Node.js: 16.14.2 V8: 10.2.154.15-electron.0 OS: Darwin arm64 21.6.0 Sandboxed: No

Extension version: 1.24.3 VS Code version: Code 1.74.0 (Universal) (5235c6bb189b60b01b1f49062f4ffa42384f8c91, 2022-12-05T16:43:37.594Z) OS version: Darwin arm64 21.6.0 Modes: Sandboxed: No

System Info |Item|Value| |---|---| |CPUs|Apple M1 Max (10 x 24)| |GPU Status|2d_canvas: enabled
canvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_renderer: enabled_on
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: disabled_off| |Load (avg)|2, 2, 2| |Memory (System)|64.00GB (32.10GB free)| |Process Argv|--crash-reporter-id 934e8b32-9713-4d8f-957f-354420e03177| |Screen Reader|yes| |VM|0%|
A/B Experiments ``` vsliv368:30146709 vsreu685:30147344 python383cf:30185419 vspor879:30202332 vspor708:30202333 vspor363:30204092 vslsvsres303:30308271 pythonvspyl392:30443607 vserr242cf:30382550 pythontb:30283811 vsjup518:30340749 pythonptprofiler:30281270 vsdfh931:30280409 vshan820:30294714 vstes263cf:30335440 vscoreces:30445986 pythondataviewer:30285071 vscod805cf:30301675 binariesv615:30325510 bridge0708:30335490 bridge0723:30353136 cmake_vspar411:30581797 vsaa593:30376534 pythonvs932:30410667 cppdebug:30492333 vsclangdc:30486549 c4g48928:30535728 dsvsc012:30540252 azure-dev_surveyone:30548225 pyindex848:30577860 nodejswelcome1:30587005 2e4cg342:30602488 gswce1:30612156 iaj6b796:30613358 dbltrim-noruby:30604474 89544117:30613380 fim-prod:30623723 ejf25101:30620729 ```
huyz commented 1 year ago

Please stop with the annoying +1 and "same issue" posts. Just thumb up the OP so that we can stay subscribed to this thread without reading dumb me-too posts

igniscyan commented 1 year ago

Please stop with the annoying +1 and "same issue" posts. Just thumb up the OP so that we can stay subscribed to this thread without reading dumb me-too posts

+1 to this also

ddnomad commented 1 year ago

Please stop with the annoying +1 and "same issue" posts. Just thumb up the OP so that we can stay subscribed to this thread without reading dumb me-too posts

Not trying to stir any hostilities here, but having some sort of an acknowlegment from maintainers that they are aware this is an issue and are working (at their own pace!) towards resolving it would probably help to put people at ease and reduce amount of "me too" here.

lperson commented 1 year ago

+1

Please stop with the annoying +1 and "same issue" posts. Just thumb up the OP so that we can stay subscribed to this thread without reading dumb me-too posts

Not trying to stir any hostilities here, but having some sort of an acknowlegment from maintainers that they are aware this is an issue and are working (at their own pace!) towards resolving it would probably help to put people at ease and reduce amount of "me too" here.

acidjazz commented 1 year ago

@J-Fields @johnfn @jpoon @xconverge @Chillee any idea what could have caused this?

alexwilkerson commented 1 year ago

i think we have discovered the hardest engineering problem known to man

khavq commented 1 year ago

same here vscodevim: v1.24.3 Visual Studio Code: 1.75.0 OS: MacOS 13.2 (22D49)

ggsggs commented 1 year ago

I had this issue only when connecting to a remote machine. On my local, latest update, it was working fine.

I uninstalled the VSCodeVim extension from the remote, restarted VSCode, installed the VSCodeVim extension and it was working as expected.

lperson commented 1 year ago

We're all software engineers. Can we put up a PR to fix this rather than piling on with complaints?

I haven't had time to dig into the code but I found a PR that touched registers from late last year. It shipped in 1.24.3. That's probably where I'd start looking.

igniscyan commented 1 year ago

We're all software engineers. Can we put up a PR to fix this rather than piling on with complaints?

I haven't had time to dig into the code but I found a PR that touched registers from late last year. It shipped in 1.24.3. That's probably where I'd start looking.

We need one of the maintainer's eyes on the PR for it to have any effect, any sort of acknowledgement would be good here.

lperson commented 1 year ago

I find that proposing a solution is often more effective than complaining about the problem.

We're all software engineers. Can we put up a PR to fix this rather than piling on with complaints? I haven't had time to dig into the code but I found a PR that touched registers from late last year. It shipped in 1.24.3. That's probably where I'd start looking.

We need one of the maintainer's eyes on the PR for it to have any effect, any sort of acknowledgement would be good here.

igniscyan commented 1 year ago

I find that proposing a solution is often more effective than complaining about the problem.

We need one of the maintainer's eyes on the PR for it to have any effect, any sort of acknowledgement would be good here.

So far the only complaints on this issue thread are about the way people are using the issue thread, lol.

stefangluszek commented 1 year ago

Same issue for me:


Commit: e2816fe719a4026ffa1ee0189dc89bdfdbafb164
Date: 2023-02-01T15:29:17.766Z
Electron: 19.1.9
Chromium: 102.0.5005.194
Node.js: 16.14.2
V8: 10.2.154.23-electron.0
OS: Linux x64 5.14.0-1056-oem
Sandboxed: No```
franchesoni commented 1 year ago

How can I provide relevant information to help reproduce the issue? It's annoying

felipeek commented 1 year ago

Same here :(

@edit: Posting "+1" or "Same here" should not be interpreted as unnecessary flooding. It should be, instead, interpreted as a nice way to show to the maintainers that the issue is affecting a large user-base. That's my goal :)

aromeronavia commented 1 year ago

Please stop with the annoying +1 and "same issue" posts. Just thumb up the OP so that we can stay subscribed to this thread without reading dumb me-too posts

+1

acidjazz commented 1 year ago

+1 also keeps the issue alive - emojis do not IIRC

scotran commented 1 year ago

+1 Same issue on Fedora 37 (Don't think there is an issue on my MacOS setup). Almost making my Linux setup unusable.

ddnomad commented 1 year ago

+1 Same issue on Fedora 37 (Don't think there is an issue on my MacOS setup). Almost making my Linux setup unusable.

MacOS is affected in my case. It shares config with Linux so that somewhat makes sense.

Also still no acknowledgment from the maintainers 🥲

I guess I will attempt to migrate to VSCode Neovim.

Elia-Darwish commented 1 year ago

@ddnomad I am only on MacOS and still have the issue since the update

Yves-air commented 1 year ago

same

ianchanning commented 1 year ago

Can someone even explain how the U shortcut is working? It's not in the list of shortcuts, unlike all the others such as HJKL and Ctrl+R.

image

Yves-air commented 1 year ago

@ianchanning

I assume it is part of the VIM extension, not the shortcuts. BTW I don't know where you see HJKL, or more specifically, they are there but certainly not for the VIM commands (they seem to be related to lists).

ianchanning commented 1 year ago

Ok, digging into it a bit the U key is running the :u[ndo] command. Calling that directly fails to. So its somewhere in the implementation of the undo command. It doesn't seem like any of the code around the undo handling has changed in a long time - so my guess is that something in the underlying vscode has impacted this.

ianchanning commented 1 year ago

@ianchanning

I assume it is part of the VIM extension, not the shortcuts. BTW I don't know where you see HJKL, or more specifically, they are there but certainly not for the VIM commands (they seem to be related to lists).

@Yves-air In the keyboard shortcuts, if you put quotes around the term "J" it filters by keybinding:

image

Yves-air commented 1 year ago

@ianchanning

I did, but I was looking at the wrong thing, I was focused (no pun intended) on the "Command" column, which has nothing to hint at the job of J in VIM, and didn't see the "Source" column.

ianchanning commented 1 year ago

@Yves-air more specifically the Focus Next Cell Editor is the DownArrow / J:

image

ianchanning commented 1 year ago

However U is doing something different - it's implementing the :undo command which has stopped working. You can try the same and after running :u a couple of times it stops working.

ianchanning commented 1 year ago

This is where the key is registered:

https://github.com/VSCodeVim/Vim/blob/e7075ad72e5b31b980ab52e9881b2b6a7b3bd673/src/actions/commands/actions.ts#L773-L792

ianchanning commented 1 year ago

Relevant undo discussion https://github.com/VSCodeVim/Vim/issues/1490 which answers my question why you can't simply map U to VSCode's 'undo'.

ianchanning commented 1 year ago

You can update the logging to debug for debugging this: https://github.com/VSCodeVim/Vim#debugging-remappings

Will-Low commented 1 year ago

I tried downgrading the extension to 1.22.0 using VS Code 1.75.0 Darwin arm64 21.6.0 and am still running into the problem. Definitely seems like something changed on the VS Code side.

ianchanning commented 1 year ago

You can access old versions of VS Code if anyone wants to find if there's a specific point at which it changed - @slnc mentioned v1.72.2.

I'm trying to debug the extension but somethings don't seem quite right.

I've set the extension settings to debug as suggested which does show up some popup alerts but nothing helpful so far.

settings.json:

    "vim.debug.loggingLevelForConsole": "debug",
    "vim.debug.loggingLevelForAlert": "debug",

However its only showing 'Popup alerts' not console logs. As I understand I should be able to see the extension logs in the Output panel: image

The Popup alerts I'm getting:

Screenshot from 2023-02-10 21-29-31

ianchanning commented 1 year ago

I've also removed all other extensions except those that I view as critical for my work:

image

Plus I uninstalled and removed any settings changes or keyboard shortcut changes that I had done to the Vim extension. Then I re-installed the plugin and re-started VSCode.

ianchanning commented 1 year ago

From @marchbox 's original comment:

I just upgraded to VS Code 1.74.0 today, and started noticing an issue with undo command ("u") in Vim. It appears to only go back 2-3 iterations (my current Vim: History setting is "50"). And if I hit CTRL+Z, it first undoes what "u" just undid, then start actually undoing

It's worth noting:

It appears to only go back 2-3 iterations (my current Vim: History setting is "50")

The 'History' "vim.history" setting is how many commands like :u, :wqthat you have done not how many undo steps you should have. I had changed this value and thought this might be problem but then realised it's a completely different thing. You can see that history log in~/.config/Code/User/globalStorage/vscodevim.vim/.cmdline_history`.

And if I hit CTRL+Z, it first undoes what "u" just undid

That's because U actually adds a step according to VSCode's history (or something like that). You can't mix Vim's undo tree with VSCode's undo.

ianchanning commented 1 year ago

I've found the debug statements now. You need to open up the literal Electron/Chrome Developer Tools within VSCode via Help > Toggle Developer Tools

image

It's the HistoryTracker logs we're interested in.

ddnomad commented 1 year ago

For any people interested in switching to VSCode Neovim, it seems to be fairly painless.

I have tested out the extension and it is pretty nice. Has more moving parts, a bit weird and requires some getting used to, but overall it does the job and comes with more flexibility in terms of doing things within init.lua or init.nvim.

It does require having neovim installed on your host, but I rely on it a lot anyways, so that is not a big issue for me.

As always, your experience may vary.

Changes necessary to make it work: https://github.com/ddnomad/dotfiles/commit/d060fb7d3d66c682e729695a954ea0bb3f956593

igniscyan commented 1 year ago

I've found the debug statements now. You need to open up the literal Electron/Chrome Developer Tools within VSCode via Help > Toggle Developer Tools

image

It's the HistoryTracker logs we're interested in.

Does this log show the error happening on your end? Or is this just a screenshot of the logs working?

ianchanning commented 1 year ago

I do wonder what the success of the VSCode Neovim project will have on this project. Also for https://v2.onivim.io/.

Edit: Ah OniVim development already stopped 2 years ago https://github.com/onivim/oni2/issues/3811#issuecomment-910306404 :disappointed:

ianchanning commented 1 year ago

I've found the debug statements now. You need to open up the literal Electron/Chrome Developer Tools within VSCode via Help > Toggle Developer Tools image It's the HistoryTracker logs we're interested in.

Does this log show the error happening on your end? Or is this just a screenshot of the logs working?

@igniscyan Just the debug logs - doesn't show the error that I've seen so far. I'm just dumping my thoughts on here because I have no idea about debugging VSCode extensions :see_no_evil:

Though worth noting that even after me trying to delete any other extensions and removing all vscodevim settings I still get the error.

ddnomad commented 1 year ago

I do wonder what the success of the VSCode Neovim project will have on this project. Also for https://v2.onivim.io/.

I do look forward to finding time to switch to VSCodium (especially in light of https://github.com/iocave/customize-ui/issues/156) and using OpenVSX as an extensions marketplace. Given that OniVim uses the same marketplace and VSCodium has VSCode Neovim, I tend to be rather sceptical of OniVim's future, especially as it uses a rather exotic framework for its UI (Revery).

Only time will tell.

ianchanning commented 1 year ago

Further investigating problems around the bug, if I:

Unfortunately there's no debug logging around inserting / removing from the VSCodeVim history.

From what I can tell though the UndoStack just seems to be a list: https://github.com/VSCodeVim/Vim/blob/master/src/history/historyTracker.ts#L226

It seems like its a straight list and not an undo tree as Vim has...

Here's the differences https://github.com/VSCodeVim/Vim/issues/1490#issuecomment-295334612 - although I have to say I'm still a bit confused as to the differences.

Are there any examples of things that will fail with Ctrl+Z / Ctrl+Shift+Z (avoids Ctrl+Y conflict)?

Things like surround.vim changes seem to happily undo.

You also get the benefit that the regular VSCode handles removing the dirty bit properly.

Stratovarius93 commented 1 year ago

I have same problem. Any solution ?

aromeronavia commented 1 year ago

I switched to use the VSCode NeoVim plugin. Pretty straightforward. Also, happy to pair program with literally anyone in this forum to see if we can find the root cause for this, I'd love to jump back to this project, the plugin is really unusable without this

EDIT: This comment solved it all https://github.com/VSCodeVim/Vim/issues/8157#issuecomment-1426704638 I'm now back to this plugin

albicasty commented 1 year ago

+1, unusable VSCodeVim.

magdyamr542 commented 1 year ago

When mapping the u to vscode's Undo and <Ctrl-r> to vscode's Redo in settings.json it works for me again. 

 "vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": [
        "u"
      ],
      "commands": [
        "undo"
      ]
    },
    {
      "before": [
        "c-r"
      ],
      "commands": [
        "redo"
      ]
    }
  ],
tjfulle commented 1 year ago

Same problem here.

ianchanning commented 1 year ago

So simplifying my earlier bug report:

Here is the debug log for this:

ModeHandler: debug: handleKeyEvent('y') took 1ms
ModeHandler: debug: handling key=y.
Remapper: debug: trying to find matching remap. keys=y,y. mode=Normal. keybindings=normalModeKeyBindingsMap.
Remapper: verbose: key=y,y. keySlice=yy.
Remapper: debug: normalModeKeyBindingsMap. potential remap broken. resending keys without allowing a potential remap on first key. keys=y,y
ModeHandler: debug: handling key=y.
Remapper: debug: trying to find matching remap. keys=y. mode=Normal. keybindings=normalModeKeyBindingsMap.
ModeHandler: debug: handleKeyEvent('y') took 3ms
ModeHandler: debug: handling key=y.
Remapper: debug: trying to find matching remap. keys=y. mode=Normal. keybindings=operatorPendingModeKeyBindingsMap.
ModeHandler: debug: handleKeyEvent('y') took 4ms
ModeHandler: debug: handleKeyEvent('y') took 9ms
ModeHandler: debug: handling key=p.
Remapper: debug: trying to find matching remap. keys=p. mode=Normal. keybindings=normalModeKeyBindingsMap.
Transformer: debug: Adding Transformation {"type":"moveCursor","diff":{"type":0,"line":21,"character":8},"cursorIndex":0}
Transformer: debug: Adding Transformation {"type":"replaceText","range":[{"line":20,"character":68},{"line":20,"character":68}],"text":"\n        captureException(`Failed to start server. ${error.message}`)"}
ModeHandler: debug: Selections: Adding Selection Change to be Ignored! (total: 1) Hash: [21, 8; 21, 8], Selections: [21, 8], [21, 8]
ModeHandler: debug: handleKeyEvent('p') took 18ms
Extension Startup: debug: Selections: Ignoring selection: [21, 8; 21, 8], Count left: 0
ModeHandler: debug: handling key=u.
Remapper: debug: trying to find matching remap. keys=u. mode=Normal. keybindings=normalModeKeyBindingsMap.
ModeHandler: debug: handleKeyEvent('u') took 1ms

If I close and restart VSCode it does briefly work (I don't know at what point it stops):

ModeHandler: debug: handling key=y.
Remapper: debug: trying to find matching remap. keys=y. mode=Normal. keybindings=normalModeKeyBindingsMap.
Remapper: debug: normalModeKeyBindingsMap. potential remap found. waiting for other key or timeout to finish.
ModeHandler: debug: handleKeyEvent('y') took 2ms
ModeHandler: debug: handling key=y.
Remapper: debug: trying to find matching remap. keys=y,y. mode=Normal. keybindings=normalModeKeyBindingsMap.
Remapper: verbose: key=y,y. keySlice=yy.
Remapper: debug: normalModeKeyBindingsMap. potential remap broken. resending keys without allowing a potential remap on first key. keys=y,y
ModeHandler: debug: handling key=y.
Remapper: debug: trying to find matching remap. keys=y. mode=Normal. keybindings=normalModeKeyBindingsMap.
ModeHandler: debug: handleKeyEvent('y') took 3ms
ModeHandler: debug: handling key=y.
Remapper: debug: trying to find matching remap. keys=y. mode=Normal. keybindings=operatorPendingModeKeyBindingsMap.
ModeHandler: debug: handleKeyEvent('y') took 5ms
ModeHandler: debug: handleKeyEvent('y') took 10ms
ModeHandler: debug: handling key=p.
Remapper: debug: trying to find matching remap. keys=p. mode=Normal. keybindings=normalModeKeyBindingsMap.
Transformer: debug: Adding Transformation {"type":"moveCursor","diff":{"type":0,"line":21,"character":8},"cursorIndex":0}
Transformer: debug: Adding Transformation {"type":"replaceText","range":[{"line":20,"character":68},{"line":20,"character":68}],"text":"\n        captureException(`Failed to start server. ${error.message}`)"}
HistoryTracker: debug: Set nextStepStartPosition to [20, 27]
HistoryTracker: debug: Finished history step with 1 change(s)
ModeHandler: debug: Selections: Adding Selection Change to be Ignored! (total: 1) Hash: [21, 8; 21, 8], Selections: [21, 8], [21, 8]
ModeHandler: debug: handleKeyEvent('p') took 35ms
Extension Startup: debug: Selections: Ignoring selection: [21, 8; 21, 8], Count left: 0
ModeHandler: debug: handling key=u.
Remapper: debug: trying to find matching remap. keys=u. mode=Normal. keybindings=normalModeKeyBindingsMap.
ModeHandler: debug: Selections: Adding Selection Change to be Ignored! (total: 1) Hash: [20, 27; 20, 27], Selections: [20, 27], [20, 27]
ModeHandler: debug: handleKeyEvent('u') took 19ms
Extension Startup: debug: Selections: Ignoring selection: [20, 27; 20, 27], Count left: 0

Here's the diff (Vim still does diffs better than VSCode ;)):

image

Two critical logs that appear in the working version but not in the failing version:

HistoryTracker: debug: Set nextStepStartPosition to [20, 27]
HistoryTracker: debug: Finished history step with 1 change(s)

Not sure about this rest...

hpurmann commented 1 year ago

Thank you for the reproducing example, @ianchanning. I am able to cause this bug consistently with your method using vscode 1.75.1 and vim-extension v1.24.3.

However, I'm not able to reproduce this with OSS vscode built from source on tag 1.75.1 and only installing vscode-vim v1.24.3 via vsix. No problem undoing whatsoever.

meronogbai commented 1 year ago

Have been dealing with this for the past few days as well