Because the default Ctrl-B/F
or PageUp/Down
behaviour usually leaves the cursor somewhere other than where it started, I remapped PageUp
and PageDown
in my .vimrc
to simply move up/down 25 lines.
nnoremap <silent> <PageUp> 25<Up>
nnoremap <silent> <PageDown> 25<Down>
But if I get to the top of the file the line number goes to 1 and so when I return down to near the original text it is now on the wrong line.
Is there some way to correct for this (perhaps some function for PageUp
and PageDown
that remembers when it could only go a lesser distance and so the first movement in the opposite direction also goes a lesser distance, or possibly some scheme where a marker is placed at the original spot... although I'd prefer not to have to remember to do that manually every time, just in case I may find myself needing it because I try to scroll too far).
I use Fedora 28 (but I'm pretty sure vi/vim under other systems had this problem of returning to a different line). Ctrl-B/F
have the side effect of moving the cursor to the last/first line on the screen, so I often find the process of looking at something off the top of the screen means returning afterwards does not actually return me to the correct line; I have to hit up/down arrows a lot. And PageUp/Down
keys are mapped to Ctrl-B/F
so have this annoying feature. Using Ctrl-U/D
or my simple workaround is usually better, except if I accidentally try to go too far... hence my question of a more general solution.
:set nostartofline
?PageUp
andPageDown
keystrokes even when the text on the screen returns to where it was (if the cursor began on one of the middle lines within the screen). I presume this isn't unique to my particular Fedora implementation. It seems so annoying that I presume others have already found a solution to it, one better than my simple workaround that fails if I try to scroll too far.