Vscode-neovim: dot-repeat problems

[asvetliakov]

I tried the version posted in this thread. It works in some cases (changing a word, appending to end of line), but not in others.
Repeating the edit of oword acts like a paste of a new line and the word wherever your cursor is.
Repeating the edit of inew word would sometimes work and sometimes only insert the last part of it. I think it was the space and the second word, but I couldn't get it consistent.
Repeating the edit of A (2) replaces the last character in the line with ')'. I believe this has to do with vs code auto-completing the close parenthesis.

_Originally posted by @ngharrison in https://github.com/asvetliakov/vscode-neovim/pull/173#issuecomment-592776169_

[chmac]

I also see weird issues around dot repeats. I issue the following series of commands:

• i
• Type foo
• Press esc
• Press .

I expected it would repeat the foo insertion, but it actually moves my cursor one character left. Doesn't seem linked to which file type, same in typescript or text files...

[asvetliakov]

@chmac The issue is for unreleased version from #173 . In the latest released dot repeat doesn't work at all.

[newhook]

When will the dot problem fix be released? Its amazingly annoying. Anything I can do to help?

[archilkarchava]

Noticed that the problem shows itself when I type too fast.

[ptasz3k]

The same happens to me. Changing a word with cw works, then using dot-repeat acts as dw (it deletes the word and does not insert new text).

[JustinHoyt]

I also have issues with this that keeps me from using the plugin since I use the dot operator with change operator so frequently.

I'd be more than happy to work on this bug if I can be pointed in the right direction or if someone would like to pair remotely on it.

[ewilazarus]

I'm facing this problem as well. Just let me know if any help is needed.

[mpth]

Not working for me either 😐

[srinivasan-r]

Not working for me either. dot operator is one of the key reason to use vim.
Please fix it ASAP.

[asvetliakov]

Sorry for the silence guys, was sorting out life problems. Will be back working on it soon

[srinivasan-r]

Sorry for the silence guys, was sorting out life problems. Will be back working on it soon

Sorry, i didn't knew you were from Spain.
Please take care of your family and health.

[mpth]

@asvetliakov don't stress yourself out over this ❤️

[willzhqiang]

The same problem with me.

[jensbodal]

Hope everything is going well at home.

I don't have prior experience with writing vscode extensions or debugging but I took a quick stab at looking into this. I was going to start with a unit test to reproduce the problem, then see if I could figure out fixing it, but first thing I see is that the unit test passes (whereas it fails if I execute the commands manually).

    it.only("Change word", async () => {
        const doc = await vscode.workspace.openTextDocument({
            content: ["abc1", "abc2", "abc3"].join("\n"),
        });

        await vscode.window.showTextDocument(doc, vscode.ViewColumn.One);
        await wait(1000);

        await sendVSCodeKeys("gg0");
        await sendVSCodeKeys("cw");
        await sendVSCodeKeys("changed");
        await sendEscapeKey();
        await sendVSCodeKeys("j0");
        await sendVSCodeKeys(".");

        await assertContent(
            {
                content: ["changed", "changed", "abc3"],
            },
            client,
        );
    })

If I open a new document and do the same commands, it does not work:

(new document)

# original text
abc1
abc2
abc3

# nvim commands in vscode #
gg0      # go to beginning of first line
cw       # change word
changed  # type out word "changed"
<esc>    # press escape key
j0       # go to beginning of next line
.        # press period to repeat

# result
changed

abc3

The behavior of running the commands manually is that it deletes line 2 instead of changing abc2 => changed.

Not sure if this is helpful but not sure where to go from here other than building and using the extension then debugging that way.

[jensbodal]

Well that explains it, it works if you build the current source code.

So until we get a new version, you can just install it from source:

yarn global add vsce
git clone https://github.com/asvetliakov/vscode-neovim.git
cd vscode-neovim
yarn install
vsce package

That will generate a vscode-neovim-0.0.50.vsix file.

Now in VSCode go to extensions, click the ellipsis at the top, and click install from vsix.

[srinivasan-r]

Well that explains it, it works if you build the current source code.

So until we get a new version, you can just install it from source:

yarn global add vsce
git clone https://github.com/asvetliakov/vscode-neovim.git
cd vscode-neovim
yarn install
vsce package

That will generate a vscode-neovim-0.0.50.vsix file.

Now in VSCode go to extensions, click the ellipsis at the top, and click install from vsix.

Thanks you. It works.

[azizghuloum]

I'm experimenting with disabling the extension's special treatment of insert mode.

It seems to be fixing probably all of the dot-repeat issues and introducing some in return :-)

I'm test driving it for the upcoming days to see what breaks.

https://github.com/asvetliakov/vscode-neovim/pull/237

[asvetliakov]

@azizghuloum
The problem with handling the insert mode in neovim itself - is the long and sad story about performance and "type" vscode event. Once it's listening type events in insert mode it starts to lag

[azizghuloum]

@asvetliakov I totally understand the sentiment ... a slow editor is a dead editor, but I would also take a correct but slow editor (as in network speed, up to say 100ms) over a fast editor with nonworking dot-repeat.

Looking at the code and how it's trying to emulate nvim's insert mode tells me (1) it's way too complex to be correct, and, (2) even if you add more complexity and more code and handle more edge cases, nvim, behind the scenes will be doing things differently that you're not handling. I think it's a losing battle. (the only reason I'm using this vim extension and not the other one is precisely because that one is trying to emulate while this one promised to offload the work to the real thing and get the real behavior)

Back to the speed issue, in my broken fork which I've been using for 12 hours a day for 3 days now, I personally have not noticed any lag issues beyond normal. Maybe I'm not using it like you do, but I do edit some 3000 line typescript files, and I usually have more than 10 files open, and yeah, it's not vim speed, but it's the normal speed you'd expect being in vscode.

Anyways, I'm carrying on with the experiment in whatever free time I have (which is not much). I would like to fix the auto inserts issue that I have (like when you type an open paren ( and vscode automatically inserts the close paren ), ... it's not happening here, only the open paren is inserted). Can you point me to which part of the extension handles that? I know it's not a type; it's something else but I don't know what it is.

Thanks!

[asvetliakov]

@azizghuloum
The extension was born when i got mad once again by using VSCodeVim. So no, no real insert mode unless vscode devs will have fixed their extension host (and they're not willing to do that unfortunately). The lag problem is a thing that not happens for every person or every situation - it mainly depends what extensions are you using and how large and type-intensive your project.

Let me explain why it happens:
once you handle type event you must send default:type event to character appear as we're doing it here.
Normally it's not the problem, but new characters triggers onDocumentChanged event which is being handled by other extensions, including default ones, like language server clients. And they could block extension host, e.g:

1) you open new ts file and type A
2) the press is being handled by type handler and sent back to vscode with default:type event
3) vscode handles event, display A and triggers document changed event
4) typescript extension receives document changed event and tries to provide you auto-import suggestions/autocompletion list
5) depending on your project it may take over 1 second - during this time, the extension host is blocked by TS extension (which is deserializing the results from the server, building the completion list, etc...) and blocking the other extensions
6) you type B (this usually comes fast after A) - and nothing happens because the extension is waiting.

Back to the speed issue, in my broken fork which I've been using for 12 hours a day for 3 days now, I personally have not noticed any lag issues beyond normal. Maybe I'm not using it like you do, but I do edit some 3000 line typescript files, and I usually have more than 10 files open, and yeah, it's not vim speed, but it's the normal speed you'd expect being in vscode.

As for your project, try to install @types/aws-sdk , include it somewhere in your project and see what happens.

Can you point me to which part of the extension handles that? I know it's not a type; it's something else but I don't know what it is.

This should be handled in document changed event. Need to send changes to neovim from here. It's not easy task though.

[curusarn]

Maybe a stupid question but how come this is a new issue? Did "dot-repeat" work properly before? Did it stop working because of changes in the vscode?

[srinivasan-r]

The lag problem is a thing that not happens for every person or every situation - it mainly depends what extensions are you using and how large and type-intensive your project.

@asvetliakov why not provide a toggle to disable only for users who are impacted? or better toggle it as per need basis. This will help me a lot.

[asvetliakov]

Took some time, but latest master works very well with . . There are few differences with vim . repeat explained in readme section. Going to release 0.0.52 tomorrow or at Monday. Sorry for long waiting guys!