fix(scrolling): fix c-u/c-y/c-f/c-b by deletion

[theol0403]

Problem

Window scroll commands don't move the cursor and instead just scroll the window. This differs from nvim behavior. This is because the extension intercepts the keybindings and applies vscode commands instead. The solution from #528 and #855 simply improves the logic in the plugin to move the cursor. However, this adds complexity and increases the separation from nvim.

Solution

Remove all custom code for cursor scrolling and allow nvim to handle it itself. However, I have found two problems:

• due to scrolloff=100, the scrolling commands behave strangely, and don't reach the top of the screen. c-d scrolls twice as far as it should. However, this can't be avoided according to

  vscode-neovim/src/main_controller.ts

  Line 55 in 52ff626

  // to not deal with screenrow positioning, we set height to high value and scrolloff to value / 2. so screenrow will be always constant

  . @justinmk can you think of another solution that will avoid the enforcing of scrolloff?
  

  vscode-neovim/vim/vscode-options.vim

  Line 16 in d11c2ed

  set scrolloff=100

• C-b behaves very strangely, even with scrolloff=0. Sometimes, it moves down a line. It never makes it to the top.

Fixes #293, #580, #528, and #855.

[theol0403]

I found an explanation for why neovim was not originally handling the scrolling. #361

Yep, unfortunately sending scroll commands from neovim produces jitter (at least it did last time when i've checked). It's possible to restore behaviour by disabling default ctrl+e/ctrl+y bindings and using vscode-neovim.send command instead and notifying back the extension from neovim.

I don't notice any jitter - maybe its safe to use this now?

Edit:

Maybe I'm wrong, this won't actually fix c-e and c-y.

[theol0403]

This actually incorporates what I showed in #580, forgot about that.

I'll update with H/M/L. This has the same problem though, as it is affected with scrolloff and the non-synced viewport.

[justinmk]

// to not deal with screenrow positioning, we set height to high value and scrolloff to value / 2. so screenrow will be always constant

I'm missing context here, but I wonder if this hack was done before win_viewport UI event was added to Nvim?

[theol0403]

I'm missing context here, but I wonder if this hack was done before win_viewport UI event was added to Nvim?

I'm also quite lacking in knowledge, but this seems related to #868 (comment) . I think the solution to one would be a solution to the other (as well as the solution to many other issues regarding viewport).

[justinmk]

If it's possible to remove the hacks while making some small tradeoffs (e.g. <c-b> is broken, but <c-u>/<c-d> work better), I'd lean towards that. And then figure out what is needed from Neovim (or VSCode?) to resolve the tradeoffs.

[theol0403]

Yeah, I'd say all that we need to merge this is for the scrolloff hack to be removed.

[trkoch]

I'm having trouble following. Can you bring us up to date what the status of this PR is?

[theol0403]

I'm having trouble following. Can you bring us up to date what the status of this PR is?

Sorry. Here is what happened:

• created this PR to simplify code and not require special PRs
• realised there was fundamental issue with the viewport height and scrolloff being too high, causing the native bindings to not work
• feat: allow vscode sync viewport with neovim #919 was merged, which properly syncs viewport height
• I merged this PR
• It turns out that c-u/c-d was still broken, see feat(scrolling): sync neovim scroll with vscode #993
• Pending feat(scrolling): sync neovim scroll with vscode #993, I had to revert this PR

So, the current state is "waiting for #993, currently reverted".