First of all, I just wanted to say it's great to finally have keyboard scrolling in VS Code! That said, this unexpected behavior can be quite frustrating for some of us as it breaks your flow when coding in addition to not matching the feature in other editors.

However, I can see how others might like the current behavior so they can scroll a bit to see some code for reference and then snap back to the original context that's possibly offscreen (maybe that's why the original author did it that way?)

Perhaps this is best made into a configuration flag instead of just 'fixing' it as a bug?

I agree it would be good to have this configurable, I prefer the current method.

I think it should still be labeled a bug, as the current behavior doesn't allow for you to remain in the newly-scrolled screen without using the mouse to put focus in the new position. This is because the cursor stays put even when it completely scrolls out of view. Since this is all about keyboard navigation, then requiring the mouse seems counter to the spirit of it.

Most editors have the cursor follow along at the top or bottom of the screen (depending on scroll direction) when scrolling beyond the current view. In that way, there's no jarring snap back to another location off-screen when you start moving the cursor with arrow keys again or start typing.

However, some editors additionally allow you to hit ESC to snap back to the original position in the cases where you're scrolling just to take a peek instead of wanting to stay in the new location.

@alexandrudima I can understand this may not be a high priority item and hasn't been addressed yet, even though it's quite frustrating for some of us on a daily basis. However, would you mind explaining why you removed the bug label in light of my previous comment?

@rob3c it's not a bug as it's working as intended currently, making this configurable would be adding functionality rather than fixing it.

This is probably the sort of thing we'd accept a PR for because of the priority of it, @alexandrudima do you want to add the help wanted label?

+1 for adding this functionality and have it configurable (or enabled).
This will provide same behavior as in Visual Studio, and will allow you to stay on the keyboard and not use the mouse.

In addition to Visual Studio, it would also provide the same behavior as in many other editors like Sublime Text, Notepad++, etc.

JetBrains editors (IntelliJ IDEA, WebStorm, etc.) use the current VSCode behavior by default. It's clear that they've recognized it as non-obvious and disorienting for many users since they attempt to make it less jarring by leading the eye with a smooth reverse scrolling animation back to the offscreen cursor position. They also offer separate "move if necessary" versions of each up/down scroll command to get the behavior desired in this thread.

I like that we now have editorScroll function for scrolling up and down with revealCursor parameter set to true. However I would like to disable the behavior of how the cursor jumps to the first non-whitespace character of the next line when scrolling down or previous line when scrolling up. I will open a separate issue for my idea.

To keep the number of issues in our inbox at a manageable level, we're closing issues that have been on the backlog for a long time but haven't gained traction: we look at the number of votes the issue has received and the number of duplicate issues filed. Thank you for your time and understanding.

P.S. If you disagree and feel that this issue is crucial: we're happy to listen and to reconsider.

For this particular issue, the following "workaround" exists (in keybindings.json). e.g. for going down:

    {
        "key": "ctrl+down",
        "command": "editorScroll",
        "args": {
            "to": "down",
            "by": "line",
            "revealCursor": true
        }
    }

@alexandrudima Ah! I didn't know there was a workaround. Will try that and feedback. Thanks.

@alexandrudima Pretty much ideal with the workaround, for me (although when scrolling up the cursor stays on the penultimate line for some reason). Anyway - thanks for posting that!

Thank you so much for the work around. I have been waiting for this 'fix'

Just tried the workaround:

	{
		"key": "ctrl+up",
		"command": "editorScroll",
		"when": "editorTextFocus",
		"args": 
		{
			"to": "up",
			"by": "line",
			"revealCursor": true
		}
	},
	{
		"key": "ctrl+down",
		"command": "editorScroll",
		"when": "editorTextFocus",
		"args": 
		{
			"to": "down",
			"by": "line",
			"revealCursor": true
		}
	}

Up works fine; down sometimes scrolls several lines than stops as if it has reached the end of the file; most of the time down does not respond at all.

Visual Studio Code version: 1.18.1, 2017-11-16

• Happens in a js file with folded functions; without folding seems to work fine.