Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'dd' followed by any character jumps cursor to end of file. #3713

Closed
Gurran opened this issue Apr 30, 2019 · 44 comments · Fixed by #4074
Labels

Comments

@Gurran
Copy link

@Gurran Gurran commented Apr 30, 2019

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:

  • Open any file
  • Remove a line in normal mode ('dd')
  • Enter any character

Expected behavior
Not jumping to end of file.

Environment:

  • Extension (VsCodeVim) Version: 1.7.0
  • VSCode version: 1.34.0-insider (user setup)
  • OS: Windows_NT x64 10.0.17134
  • Date: 2019-04-30T08:17.612Z

Additional 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
}
@Gurran Gurran changed the title 'dd' followed by any character, jumps cursor to end of file. 'dd' followed by any character jumps cursor to end of file. Apr 30, 2019
@Gurran

This comment has been minimized.

Copy link
Author

@Gurran Gurran commented Apr 30, 2019

Did you find a solution? @ConnorGray

Im refering to #2136 (comment) by you

@yveslange

This comment has been minimized.

Copy link

@yveslange yveslange commented Apr 30, 2019

Wow, I was just going to report the same issue. No solution for the moment on my side, very annoying !

@jeffhu1

This comment has been minimized.

@mazamats

This comment has been minimized.

Copy link

@mazamats mazamats commented Apr 30, 2019

Running into this as well

@zzJinux

This comment has been minimized.

Copy link

@zzJinux zzJinux commented May 1, 2019

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

@shepherdsam

This comment has been minimized.

Copy link

@shepherdsam shepherdsam commented May 3, 2019

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

@MacMaru

This comment has been minimized.

Copy link

@MacMaru MacMaru commented May 8, 2019

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.

@petejkim

This comment has been minimized.

Copy link

@petejkim petejkim commented May 15, 2019

👍 This really annoying

@atsukita

This comment has been minimized.

Copy link

@atsukita atsukita commented Jun 23, 2019

same, hope it will be fixed.

@xiopao

This comment has been minimized.

Copy link

@xiopao xiopao commented Jun 25, 2019

I've fixed this issue by removing this setting. I'm not using it anyway.

Screenshot from 2019-06-26 01-30-16

@cdisselkoen

This comment has been minimized.

Copy link

@cdisselkoen cdisselkoen commented Jun 25, 2019

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

@cdisselkoen

This comment has been minimized.

Copy link

@cdisselkoen cdisselkoen commented Jun 26, 2019

It can happen after other d commands as well (like d3j), not just dd.

@preciserobot

This comment has been minimized.

Copy link

@preciserobot preciserobot commented Jun 27, 2019

Same behaviour here. It makes VSCodeVim unusable for me at the moment. As @cdisselkoen points out this affects almost any d command for me.

@vaidotasp

This comment has been minimized.

Copy link

@vaidotasp vaidotasp commented Jun 27, 2019

Same here, this issue really needs attention as unpredictable behavior makes the extension virtually unusable.

@tmerse

This comment has been minimized.

Copy link

@tmerse tmerse commented Jul 2, 2019

Same here

@elprans

This comment has been minimized.

Copy link

@elprans elprans commented Jul 4, 2019

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:

  1. Open a file.
  2. Open the same file in another pane, move cursor to the end of file (or any other line, doesn't matter)
  3. Switch to the first pane and issue dd followed by any key.
  4. Cursor in pane 1 jumps to the line which is the current one in pane 2.

To fix this, VSCodeVim must take into account not just the fileName, but also the viewColumn attribute of the TextEditor instance.

@hexagon6

This comment has been minimized.

Copy link

@hexagon6 hexagon6 commented Jul 6, 2019

It might be related to a change in editor-behaviour (actually quite a while ago)

@helloncanella

This comment has been minimized.

Copy link

@helloncanella helloncanella commented Jul 7, 2019

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.

@adam-lee

This comment has been minimized.

Copy link

@adam-lee adam-lee commented Jul 13, 2019

I got nothing to add except that this is happening on VS Code Version 1.36.1 with Vim 1.8.1. Really annoying.

@cottrell

This comment has been minimized.

Copy link

@cottrell cottrell commented Jul 16, 2019

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

@cottrell

This comment has been minimized.

Copy link

@cottrell cottrell commented Jul 16, 2019

@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
@Gurran

This comment has been minimized.

Copy link
Author

@Gurran Gurran commented Jul 16, 2019

@elprans

This comment has been minimized.

Copy link

@elprans elprans commented Jul 16, 2019

I can confirm that this can be reproduced in 1.0.5, but not in 1.0.4

@fredrike

This comment has been minimized.

Copy link

@fredrike fredrike commented Jul 23, 2019

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

Will use https://github.com/74th/vscode-vim until this is resolved.

@Gurran

This comment has been minimized.

Copy link
Author

@Gurran Gurran commented Jul 23, 2019

@willmcf

This comment has been minimized.

Copy link

@willmcf willmcf commented Jul 24, 2019

Ditto

@kaijajan

This comment has been minimized.

Copy link

@kaijajan kaijajan commented Jul 30, 2019

this bug is really annoying, all the joy using this extension all gone

@Gurran

This comment has been minimized.

Copy link
Author

@Gurran Gurran commented Jul 31, 2019

@cottrell

This comment has been minimized.

Copy link

@cottrell cottrell commented Aug 1, 2019

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

@fredrike

This comment has been minimized.

Copy link

@fredrike fredrike commented Aug 1, 2019

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.

@kaijajan

This comment has been minimized.

Copy link

@kaijajan kaijajan commented Aug 1, 2019

@fredrike I encountered this issue on editing typescript files

@J-Fields J-Fields added the kind/bug label Aug 5, 2019
@wrmoon

This comment has been minimized.

Copy link

@wrmoon wrmoon commented Aug 7, 2019

Happens for me on:
VsCodeVim v1.9.0
vscode 1.36.1
MacOS 10.14.6

@burabure

This comment has been minimized.

Copy link

@burabure burabure commented Aug 9, 2019

same issue here, it makes the extension almost unusable

@bedge

This comment has been minimized.

Copy link

@bedge bedge commented Aug 10, 2019

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 -> EOF
Cmd-Shift-K -> EOF
Insert mode Shift highlight, then Delete, OK

Does seem to be limited to vim command mode.

@fredrike

This comment has been minimized.

Copy link

@fredrike fredrike commented Aug 11, 2019

@jpoon do you know what happened between v1.0.4...v1.0.5 that made dd jump to end of file?

@jpoon

This comment has been minimized.

@fredrike

This comment has been minimized.

Copy link

@fredrike fredrike commented Aug 13, 2019

https://github.com/vscodevim/vim/compare/v1.0.4…v1.0.5

Yes, I did post that @ #3713 (comment), 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..

@petejkim

This comment has been minimized.

Copy link

@petejkim petejkim commented Aug 15, 2019

Downgraded to 1.0.4 as well and it seems to be working fine

@orn688

This comment has been minimized.

Copy link
Contributor

@orn688 orn688 commented Sep 9, 2019

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:

  1. dd -> deletes the current line (somewhere in the middle of the file)
  2. V -> jumps to the end of the file (not expected)
  3. u -> does nothing (not expected)
  4. u -> undeletes the line and jumps back to that line

the significant part (besides the known dd bug) being that I have to press u twice to get it to undo the deletion.

@oxalica

This comment has been minimized.

Copy link
Contributor

@oxalica oxalica commented Sep 13, 2019

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 <git@jasonpoon.ca>
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(-)
@ryankeener

This comment has been minimized.

Copy link

@ryankeener ryankeener commented Sep 13, 2019

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

return require('util').promisify(setTimeout)(() => {
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;
}
}, 0);
}

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.

@J-Fields

This comment has been minimized.

Copy link
Collaborator

@J-Fields J-Fields commented Sep 15, 2019

@ryankeener Now setImmediate is used, so I don't think this is the cause. See f58400c#diff-a7723f32fe6b05e135838f84e5c23c0fR81

@ryankeener

This comment has been minimized.

Copy link

@ryankeener ryankeener commented Sep 16, 2019

@J-Fields good catch, I should have checked that. The only other thing I noticed in that commit was that

this._disposables.push(this.vimState);

is now executed before setCurrentMode resolves whereas previously it was done before after but I haven't looked any further into that.

@J-Fields

This comment has been minimized.

Copy link
Collaborator

@J-Fields J-Fields commented Sep 25, 2019

More discussion: #3804

J-Fields added a commit that referenced this issue Sep 25, 2019
Fixes #3713 , hopefully.
This happened when you were editing a file in two splits at once. An edit in one split that affected the cursor position in the other split would trigger an extra `onDidChangeTextEditorSelection` event that we should be ignoring.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.