Cursor movement in wrapped lines changed from 1.10.2 to 1.11.0 #4120
Comments
|
Can you confirm it works with no line wrapping? We fixed |
|
When turning word wrapping off, |
|
No worries. Downgrading the extension is simple enough, so it's not to difficult to work around right now. |
|
Turns out fixing this is impossible because of the limitations of the VSCode API and the way VSCodeVim interacts with the editor cursors. I will submit a PR to more or less reverse the previous change with additional explanations for anyone looking into this in the future. |
This more or less reverts the functionality introduced by commit 4b2e079 and raised in issue VSCodeVim#3890. Unfortunately it is not currently possible to fully implement display line movements over wrapped lines that will always preserve cursor position. One of two things is necessary to change this, either the VSCode API needs to be extended to return information about wrapped lines (but this was rejected in issue microsoft/vscode#23045). Alternatively VSCodeVim would need to reïimplement all motions using vscode.commands.executeCommand() commands rather than manipulating vscode.window.activeTextEditor.selections directly, as the former preserves column position while the latter does not. However it's not clear to me if all VIM beahviour could be reïmplemented this way without first trying this out and sounds like a bit of a ground up rewrite. It seems for now we're stuck with gj/gk not preserving column position when jumping across short lines.
|
Not sure why the pull request wasn't automatically reference by GitHub but the PR to revert to the previous behaviour is found at #4127 |
|
Looks like since this issue wasn't mentioned in the pull request itself it doesn't get referenced (even though you referenced it in the commit. |
Yes, you're right . It has to be mentioned in the body of the issue description and not the title. Though oddly enough GitHub picked up the title mention from the repository where the pull request came from... |
Closes #4120 This more or less reverts the functionality introduced by commit 4b2e079 and raised in issue #3890. Unfortunately it is not currently possible to fully implement display line movements over wrapped lines that will always preserve cursor position. One of two things is necessary to change this, either the VSCode API needs to be extended to return information about wrapped lines (but this was rejected in issue microsoft/vscode#23045). Alternatively VSCodeVim would need to reïimplement all motions using vscode.commands.executeCommand() commands rather than manipulating vscode.window.activeTextEditor.selections directly, as the former preserves column position while the latter does not. However it's not clear to me if all VIM beahviour could be reïmplemented this way without first trying this out and sounds like a bit of a ground up rewrite. It seems for now we're stuck with gj/gk not preserving column position when jumping across short lines. Add gj/gk tests for future behaviour These tests had been previously removed as supporting this behaviour is not yet possible due to technical reasons, however they do represent correct VIM behaviour so we keep them until implementation becomes architecturally possible.
Describe the bug
Using the
gjandgkbinding to move by wrapped line instead of the file line does not work correctly in version 1.11.0, but works fine when downgrading to 1.10.2.Specifically, here are the issues I've experienced:
gj) by file line, but down (gk) by wrapped line. Though this behavior is inconsistent and reverses itself sometimes.To Reproduce
Go to file with lots of wrapped lines (or take a normal file and make the window really narrow) and move up and down with
gjandgk.Expected behavior
It to move by one wrapped line and maintain the same lateral character position (assuming there is a character present in that lateral character position).
Environment (please complete the following information):
Note: Manjaro currently doesn't have vscode 1.38.x on it's stable branch. This is why I'm a version behind the latest.
The text was updated successfully, but these errors were encountered: