Describe the bug
After deleting a line with dd any character afterwards jumps me to the end of the file.
This issue has been marked closed in an old Closed Issue
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Not jumping to end of file.
Environment:
1.7.01.34.0-insider (user setup)10.0.171342019-04-30T08:17.612ZAdditional context
VsCodeVim settings
{
"vim.easymotion": true,
"vim.textwidth": 140,
"vim.useCtrlKeys": false,
"vim.history": 100,
"vim.insertModeKeyBindings": [
{
"before": ["j", "j"],
"after": ["<Esc>"]
}
],
"vim.normalModeKeyBindingsNonRecursive": [
{
"before": ["<C-n>"],
"commands": [":nohl"]
}
],
"vim.leader": ",",
"vim.sneak": false,
"vim.incsearch": true,
"vim.useSystemClipboard": true,
"vim.hlsearch": true,
"vim.searchHighlightColor": "rgba(150, 150, 255, 0.3)",
"vim.surround": true
}
Did you find a solution? @ConnorGray
Im refering to https://github.com/VSCodeVim/Vim/issues/2136#issuecomment-480940723 by you
Wow, I was just going to report the same issue. No solution for the moment on my side, very annoying !
Running into this as well
I'm experiencing the same issue.
This is REALLY annoying!
VsCodeVim Version: 1.7.0
vscode Version: 1.33.1
OS: macOS 10.14.4
Closing and re-opening the file is my current workaround.
The issue doesn't happen consistently for me and I haven't traced the steps that get me into the bad state.
I believe same issue: #3694
Same issue: after saving or after deleting the cursor jumps to end of file, all the time.
Thought it might be related to interference with Beautify/Prettier that reformats on save, but disabling all plugins except for Vim still shows the jumping. Restarting does not resolve the issue, neither does installing a different version of vscode-vim (pre 1.0.2).
Previous cursor positions are gone, `` to jump back jumps from end of file to beginning of file or gives mark not set. Effectively means after every save/delete I have to remember/mark the line I was on and jump back, or if I forgot that I have to actively search/browse to where I left off.
This is a big productivity impediment, hope you can find the root cause or clue to how to resolve it.
Does not seem to be file type dependent: happens to me on Vue files/plain JS/JSON/HTML. Did not see this behavior on a previous project about six months back, but no clue what version I had installed then.
:+1: This really annoying
same, hope it will be fixed.
I've fixed this issue by removing this setting. I'm not using it anyway.

I have been having this problem intermittently even without any custom keybinding involving the d key at all. Like others on the thread, closing and re-opening the file fixes the problem for me (at least for a while). Perhaps relevant, I do have the setting "files.autoSave": "afterDelay".
It can happen after other d commands as well (like d3j), not just dd.
Same behaviour here. It makes VSCodeVim unusable for me at the moment. As @cdisselkoen points out this affects almost any d command for me.
Same here, this issue really needs attention as unpredictable behavior makes the extension virtually unusable.
Same here
This seems to be due to the fact that the extension tracks editor positions (and other state) using the name of the open file, which is obviously not unique if multiple editors are open in different panes.
Here's a reliable way to reproduce:
dd followed by any key.To fix this, VSCodeVim must take into account not just the fileName, but also the viewColumn attribute of the TextEditor instance.
It might be related to a change in editor-behaviour (actually quite a while ago)
I've fixed temporally this problem downgrading to the version 1.0.0.
Now I need to discover how to prevent vscode from reinstalling the newer versions, always I reload it.
I got nothing to add except that this is happening on VS Code Version 1.36.1 with Vim 1.8.1. Really annoying.
I just went through a bunch of versions and I think the break happens between v.1.0.4 (good) to v.1.0.5 (bad).
@jpoon my bisection test is pretty rough (just brute force installing the updates) but am hoping you maybe have a good guess about what might be behind this trigger jump between 1.0.4 and 1.0.5. looks like some async and position function changes in those ranges.
Would be interesting if anyone else on this thread @adam-lee @hexagon6 can manually confirm the versions 1.0.4 (good) and 1.0.5 (bad) by downgrading the plugin. Might still be just some interaction with other non-extension changes in vscode.
~/code/Vim $ git log v1.0.4..v1.0.5 | grep Author | cut -d'<' -f1 | cut -d: -f2 | sed -e 's/^\s//g' | sort | uniq -c
1 Ethan Setnik
39 Jason Poon
1 Pine Wu
7 Renovate Bot
2 Sean Kelly
1 Vasily Pikulev
1 pikulev
2 renovate[bot]
2 xconverge
Nice. I'll try to verify.
On Tue, 16 Jul 2019, 12:25 David Cottrell, notifications@github.com wrote:
I just went through a bunch of versions and I think the break happens
between v.1.0.4 (good) to v.1.0.5 (bad).—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/VSCodeVim/Vim/issues/3713?email_source=notifications&email_token=AKD63KMK5CDLTRRMGBAR4R3P7WOXXA5CNFSM4HJJP4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2ANGPQ#issuecomment-511759166,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKD63KPK6T4XFL5Y752QNI3P7WOXXANCNFSM4HJJP4SA
.
I can confirm that this can be reproduced in 1.0.5, but not in 1.0.4
I can confirm that this can be reproduced in 1.0.5, but not in 1.0.4
Same here, works fine in v1.04. Here are the changes for 1.0.5: https://github.com/VSCodeVim/Vim/compare/v1.0.4...v1.0.5
Will use https://github.com/74th/vscode-vim until this is resolved.
Same here. VsCodeVim is almost unusable if not set to 1.0.4.
On Tue, 23 Jul 2019, 08:41 Fredrik Erlandsson, notifications@github.com
wrote:
I can confirm that this can be reproduced in 1.0.5, but not in 1.0.4
Same here, works fine in v1.04. Here are the changes for 1.0.5:
v1.0.4...v1.0.5 https://github.com/VSCodeVim/Vim/compare/v1.0.4...v1.0.5—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/VSCodeVim/Vim/issues/3713?email_source=notifications&email_token=AKD63KJALAIFC3ZFLSLPEELQA2R2RA5CNFSM4HJJP4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2SCX2I#issuecomment-514075625,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKD63KNHNHRE3CPNONX4F5DQA2R2RANCNFSM4HJJP4SA
.
Ditto
this bug is really annoying, all the joy using this extension all gone
The thing that bugs me is that there is a bug in 1.0.4 that makes the
extension hang from time to time.
So in the old version the extension hangs, and in the new version cursor
jumps to the bottom constantly.
On Tue, 30 Jul 2019, 10:26 kaijajan, notifications@github.com wrote:
this bug is really annoying, all the joy using this extension all gone
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/VSCodeVim/Vim/issues/3713?email_source=notifications&email_token=AKD63KJ5FYIPUKXA33OWDQ3QB73MBA5CNFSM4HJJP4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3DGRAY#issuecomment-516319363,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKD63KIXCF3MDITAAXSNTUDQB73MBANCNFSM4HJJP4SA
.
Has anyone got set up in dev?
https://github.com/VSCodeVim/Vim/blob/master/.github/CONTRIBUTING.md
I'm not clear on the policy for reverting some changes but I might give it a try if I has some time this weekend.
There are a lot of open issues and not a lot of folks contributing ...
I think the issue should be isolated first. I think I had quite good experience with dd in non python files so it might be a clash between plugins.
@fredrike I encountered this issue on editing typescript files
Happens for me on:
VsCodeVim v1.9.0
vscode 1.36.1
MacOS 10.14.6
same issue here, it makes the extension almost unusable
Nothing like jumping to end of file after any line deletion to completely destroy your train of thought. I spend more time trying to think of new ways of deleting lines now.
dd
Cmd-Shift-K
Insert mode Shift highlight, then Delete, OK
Does seem to be limited to vim command mode.
@jpoon do you know what happened between v1.0.4...v1.0.5 that made dd jump to end of file?
Yes, I did post that @ https://github.com/VSCodeVim/Vim/issues/3713#issuecomment-514075625, my question were more. Do you also have this issue or an idea on what is going on here. I have not had possibility to read through all the changes..
Downgraded to 1.0.4 as well and it seems to be working fine
I can't reliably reproduce this by opening the same file in two panes, but it sometimes happen even if I have the file open in only one pane. At the moment it's happening when I try to enter visual line mode with V after deleting a line, and I'm getting some strange behavior with undoing when I perform the following series of operations:
dd -> deletes the current line (somewhere in the middle of the file)V -> jumps to the end of the file (not expected)u -> does nothing (not expected)u -> undeletes the line and jumps back to that linethe significant part (besides the known dd bug) being that I have to press u twice to get it to undo the deletion.
I do a git bisect between v1.0.4 and v1.0.5 to test @elprans 's reproductions steps,
and here is the result:
5c14677917652b802ef7552d5a26f856c000f43b is the first bad commit
commit 5c14677917652b802ef7552d5a26f856c000f43b
Author: Jason Poon <[email protected]>
Date: Wed Jan 23 13:29:24 2019 -0800
refactor: get rid of the god awful async code in ctro
extension.ts | 2 +-
src/mode/modeHandler.ts | 86 ++++++++++++++++++++--------------------------
src/mode/modeHandlerMap.ts | 11 +-----
3 files changed, 40 insertions(+), 59 deletions(-)
Thanks for doing that @uHOOCCOOHu
I'm not at all familiar with this extension (or any vscode extensions for that matter) but I'd bet it's related to the incorrect use of promisify with setTimeout node docs
instead it should be
return require('util').promisify(setTimeout)(0).then(() => {
if (this.vimState.editor) {
this.vimState.cursorStartPosition = Position.FromVSCodePosition(
this.vimState.editor.selection.start
);
this.vimState.cursorPosition = Position.FromVSCodePosition(
this.vimState.editor.selection.start
);
this.vimState.desiredColumn = this.vimState.cursorPosition.character;
this.vimState.prevSelection = this.vimState.editor.selection;
}
});
}
As it's currently implemented I don't think that code is ever getting executed.
@ryankeener Now setImmediate is used, so I don't think this is the cause. See https://github.com/VSCodeVim/Vim/commit/f58400c244350dcf3046bd824741edd82530ba43#diff-a7723f32fe6b05e135838f84e5c23c0fR81
@J-Fields good catch, I should have checked that. The only other thing I noticed in that commit was that
is now executed before setCurrentMode resolves whereas previously it was done before after but I haven't looked any further into that.
More discussion: #3804
Most helpful comment
this bug is really annoying, all the joy using this extension all gone