Vim: ctrl+d, ctrl+u not scrolling cursor the same # of lines

Created on 28 Sep 2016  ·  12Comments  ·  Source: VSCodeVim/Vim

  • Click thumbs-up 👍 on this issue if you want it!
  • Click confused 😕 on this issue if not having it makes VSCodeVim unusable.

The VSCodeVim team prioritizes issues based on reaction count.


What did you do?

Put the exact keys you pressed.

ctrl+u or ctrl+d

What did you expect to happen?

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

What happened instead?

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.

Technical details:

  • VSCode Version: Version 1.6.0-insider (c94c824db64a88bd4909da2e84e44316dbf8e8fb)
  • VsCodeVim Version: _[please ensure you are on the latest]_ 0.2.0
  • OS: macOS Sierra version 10.12.1 Beta (16B2327e) (only on “Beta” still because it won’t let me install the GM since my beta version is technically newer 😞)
kinbug statuduplicate upstreavscode

Most helpful comment

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

All 12 comments

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

Was this page helpful?
0 / 5 - 0 ratings