Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve ^F and ^B by handling 'window' and 'wrap' options #13

Closed
wants to merge 6 commits into from

Conversation

misterbuckley
Copy link

Take 'window' option into account when determining how many lines to scroll for ^F and ^B, using the logic described in :help 'window'

Also fix a small bug where ^F and ^B would not scroll the correct number of lines if the 'wrap' option was set and there were wrapped lines visible on the screen

This leaves one small issue unaddressed: in default vim, if you give ^F or ^B a count, and there are wrapped lines in the file, vim will effectively do ^F or ^B multiple times, scrolling a number of lines equal to the number of lines visible after each iteration - 1. This is significant because with 'wrap' set, the number of lines visible at each point in the file might be different, so in default vim, 3^F might not scroll exactly (3 * (line('w$') - line('w0') - 1)) lines like smoothie#backwards() and smoothie#forwards would.

also fix ^F and ^B not scrolling the correct number of lines when 'wrap'
is set

logic is taken from `:help 'window'`
@psliwka
Copy link
Owner

psliwka commented Apr 4, 2020

Thanks for your contribution, @misterbuckley! I tested your changes and, unfortunately, found a severe bug in handling Vim folds.

Steps to reproduce:

  • Open a sufficiently large file (few thousand lines or so)
  • Create a fold, f.ex. manually with zf1000j
  • Try to move over folded lines with ^F

Expected result: screen is scrolled about 'window' lines down. When the scrolling animation ends, the cursor is positioned about (1000+'window') lines forward.

Actual result: the cursor is catapulted 2000+ lines forward, far away from its intended position.

I'm not quite sure how to fix this yet.

@psliwka
Copy link
Owner

psliwka commented Feb 7, 2021

Note to myself: 'wrap' handling has been fixed via #23, but I'm keeping this one open to investigate whether we could merge the 'window' support bit from here.

@psliwka
Copy link
Owner

psliwka commented May 3, 2022

Update: closing as after f2aaab1 all wraps should be handled perfectly.

@psliwka psliwka closed this May 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants