Writing "during" AutoWrap can cause positioning issues for cursor

[flindeberg]

I have several times managed to get the cursor to find a weird position when writing "quickly" in large paragraphs (LaTeX-document) with AutoWrap-enabled.

"Quickly" here should be read as unusually fast, normally AutoWrap works fine.

To reproduce:

• smash keyboard randomly (fast) and make sure to press space every now and then

What happens:

• the keys hit "during" AutoWrap appear after the cursor on the wrapped line

What should happen:

• the keys hit "during" AutoWrap should appear just in front of the cursor rather than after the cursor, or said differently, the cursor should appear at the end of the line.

Example: While hitting asdf<space>asdf<space>asdf<space>asdf<space>asdf<space>(repeatedly) it is possible to end up in the following scenario (simulating column to break at 18):

asdf asdf asdf # as expected asdf asdf asdf # this autowrap became messed up asdf df asdf|as # | indicates cursor, and as will just go ahead of the cursor for eternity :-)

It should be like this:

asdf asdf asdf # as expected asdf asdf asdf # this autowrap became messed up asdf asdf asdf| # | indicates cursor

Idea on how to fix: (I have not looked into the codebase yet, assuming a bit here)

I assume that wrap cuts out the text to wrap, magically modifies it, and then paste it back in where the cursor was at the start of the wrap, and puts the cursor there as well. The problem is that during the wrap the cursor actually went 2-3 characters forward since the user was frantically typing and and the cursor then jumped back during the reinsert of the text.

[stkb]

Yeah I've been aware of this issue for a while: typing too fast can cause selection/cursor problems as you say. I do (locally) have a very old branch where I started to investigate putting autowrap on a debounce instead.

I don't know exactly how it's going wrong but it's basically as you say: VSCode allows us to request an edit that replaces the text between the given positions. After that the extension does some diffing to calculate where the cursor now needs to go and puts it there (because VSCode itself gets this wrong).

It's possible that VSCode has improved with the cursor/selection placement since I wrote that fix (VS-proper can do it, after all) and that last step is no longer necessary. And general perf work can also be done (and will be improved in a change I'm working on) but unfortunately it tends to get a low priority after all the other issues.

[flindeberg]

@stkb Have you tried just calling the cursorEnd command after applying the changes? I.e.:

// in checkChange for autowrap
return applyEdit(editor, edit).then(null, catchErr).then(success => {
  if (success) vscode.commands.executeCommand('cursorEnd')
})

Or I guess that might boggle some other use cases?

I'll give above a swirl next time I sit down to write, above is just a free-handed suggestion after looking at the code base in a browser.

[stkb]

cursorEnd is just the same as pressing the <end> key right? So that won't be correct in the case where you're inserting text in a line and go past the wrapping column, but still have more text to the right of the cursor. It also won't work with full (continuous) autowrapping, which I plan to support soon.

I just checked and unfortunately the cursor-repositioning is still needed, though not in all cases, so it may be possible to optimize here.

You can try experimenting on the "live" version of the extension in .vscode/extensions if you like. If you comment out the code that adjusts the selection then it should still work fine most of the time, as long as you're using LF line endings and not CRLF.

I think this is fixable, though it will take some work to work out the precise order of events.

[gwf]

I just wanted to bump this up, if possible. I get hit with this bug several times a day and I think that some other changes w/in VSCode proper is now making the issue worse.

[flindeberg]

I have temporarily worked around the issuing by SSH:ing (in vscode) to a "very powerful workstation (tm)" when on my laptop, which seems to help a lot.

[stkb]

For me this issue almost went away after upgrading my laptop, but I've now changed how the affected code works in v17.5 and I think it should help.

Now, even when mashing the keyboard as fast as possible, I can't get it to break.

[ellerychan]

I experience this problem regularly when typing quickly during an auto-wrap, on pretty snappy hardware. But it's a very handy extension so I keep using it anyway. I'm looking forward to your update that fixes this.

[stkb]

@ellerychan have you tried the pre-release version?

[ellerychan]

No, but as this sounds like an endorsement, I will. :-)

[stkb]

Yeah it can be considered pretty stable now. I'd be interested if it fixes the problem for you too.

[ellerychan]

I've been using it for a few days now and have not seen the auto-wrap problem where the insert point would end up in the wrong place on the new line and characters would get selected and deleted. That seems solid now as far as I can tell.

[sjdemartini]

I encounter this frequently, and I've found that the problem is even worse / more frequent with the pre-release version. For what it's worth, I use VSCode with Vim emulation mode (via https://marketplace.visualstudio.com/items?itemName=vscodevim.vim), which perhaps is more poorly handled.