The VSCodeVim team prioritizes issues based on reaction count.
Put the exact keys you pressed.
ctrl+u or ctrl+d
From the vim docs:
*CTRL-U*
CTRL-U Scroll window Upwards in the buffer. The number of
lines comes from the 'scroll' option (default: half a
screen). If [count] given, first set the 'scroll'
option to [count]. The cursor is moved the same
number of lines up in the file (if possible; when
lines wrap and when hitting the end of the file there
may be a difference). When the cursor is on the first
line of the buffer nothing happens and a beep is
produced. See also 'startofline' option.
{difference from vi: Vim scrolls 'scroll' screen
lines, instead of file lines; makes a difference when
lines wrap}
*CTRL-D*
CTRL-D Scroll window Downwards in the buffer. The number of
lines comes from the 'scroll' option (default: half a
screen). If [count] given, first set 'scroll' option
to [count]. The cursor is moved the same number of
lines down in the file (if possible; when lines wrap
and when hitting the end of the file there may be a
difference). When the cursor is on the last line of
the buffer nothing happens and a beep is produced.
See also 'startofline' option.
{difference from vi: Vim scrolls 'scroll' screen
lines, instead of file lines; makes a difference when
lines wrap}
I think there are other issues (#673, #675) for the respecting the [count] option and defaulting it to exactly half of the screen (respectively), so this issue is more concerned with the coordinated movement of the cursor: “The cursor is moved the same number of lines up/down in the file….”
The scrolling happens, but the cursor does not move up/down the same number of lines – it doesn't maintain it’s relative screen position.
If I understand correctly, what you're saying is that when you do c-d or c-u, the cursor should stay still relative to the window, but it actually doesn't?
@rebornix I don't think this is possible with the VSCode API. Is it?
Time to go nag those guys again. 😄
@johnfn: Yes, that is correct: the cursor should stay relatively in the same place on the screen (not the same place in the document).
Yeah, let's beef up the VSCode API! win-win!
Cant we just scroll up and change cursor position by the same amount instantly right after?
What would this look like as an API change that makes sense?
I suppose since we are using editorScroll from the API it could be a vscode API thing, but am not fully convinced it isn't a vim specific way of scrolling and positioning the cursor
+1 to @xconverge . Scrolling half of a page upwards and downwards makes perfect sense and it should be a Code feature as well but I'm not sure whether keeping cursor position relatively is too Vim specific.
Looking for others' input.
As a workaround, I use this:
"vim.otherModesKeyBindingsNonRecursive": [
{
"before": [ "ctrl+d" ],
"after": [ "ctrl+d", "M" ]
},
{
"before": [ "ctrl+u" ],
"after": [ "ctrl+u", "M" ]
}
],
Hoping to get the real solution soon, though :)
@rebornix , personally I prefer a seamless experience when transitioning from Vim to an IDE with a Vim plugin. Everything, down to the cursor position, has an effect on productivity. I am trained to expect where the cursor will be when I perform a half page up/down, to the point where I often center my cursor before paging. Personally, when it comes to Vim IDE plugins, I don't think there is such a thing as being "too Vim specific."
I believe he meant if it is too vim specific to add to the vscode API
@xconverge , well spotted. I would agree that the change to vscode is probably a bit too Vim specific. However, the functionality could probably be provided on the Code API via an optional parameter (e.g., maintainCursorRelativePosition).
Hello! Im still experiencing this problem :/ was it decided that this will not be pushed further?
@proProbe I haven't taken a look at this problem recently, but my impression is that this was a limitation of the VSCode API.
I believe this is a dupe of https://github.com/VSCodeVim/Vim/issues/1348
Most helpful comment
As a workaround, I use this:
Hoping to get the real solution soon, though :)