I’m having some trouble with the page-up/page-down function. I’m also having difficulty re-producing the problem, so when it starts to happen again I’ll come back to this post to inspect the answers given here more closely.
[I edited this post from what it was after I realised that I couldn’t re-produce the problem reliably.]
Otherwise, this post, is helpful.
I’m not seeing anything like that in build 4175. Pressing page-up/down scrolls exactly one page worth of lines. There is also the "scroll_context_lines" setting that lets you configure extra context lines.
I guess any example or screencast would help.
It wouldn’t be the first time something strange happening, only under very special circumstances.
If I just use PgUp/Dn repeatedly, it moves one page reliably. But if I move from there via Find, or a mouse cursor click, or the scrollbar, or a lot of arrow keys, PgUp/Dn still remembers where it stopped moving last time, and moves one page from there. Can be quite confusing if I’ve moved a long way with Find and want to explore from the new location.
I’d probably prefer that PgUp/Dn always move one page from the currently visible location. Maybe there is a setting for that? But now that I understand what’s happening, it hasn’t reached the top of my list to look for one.
Nearly every command works based on caret position and so do move commands.
Pressing
pageup calls move {"by": "pages", "forward": false}
pagedown calls move {"by": "pages", "forward": true}
Those commands actually move the caret by a certain amount of lines up and down. The viewport scrolling is just a side-effect to reveal new caret location.
PageUp/PageDown behavior after “find” also depends on where caret is positioned.
This is an aspect applications indeed behave different:
VS Code, gedit and Sublime Text, just start moving caret from its current caret position, even if it is far away from currently visible viewport. As a result viewport may scroll way more than a page to reveal caret’s new location.
LibreOffice Writer and Windows Notepad first move caret to currently visible viewport and start paging up/down from this new location. That’s what you probably expect to happen.
I’d say both of which have their reasons for existance.
The scheme I see is advanced code editors behaving equally as those expect keyboard navigation, primarily. Scrolling via mouse is more or less a 2nd class feature, which is often only used to quickly peek some code and quickly return to last edit position. A related feature request is https://github.com/sublimehq/sublime_text/issues/6425 for instance.
I am not aware of any setting to adjust ST’s behavior.
You can either click into visible viewport, before pressing pageup/down, to place caret into it, manually or use the following plugin.
Note: Maybe there’s an easier way to move a caret to visible viewport with an existing command, but I am not aware of it at the time of writing this post.
Packages/User/pager.py
import sublime
import sublime_plugin
class VisualMovePageCommand(sublime_plugin.TextCommand):
"""
This class describes a visual move page command.
This command moves the caret to center of visible viewport,
if it is not already within, and starts paging up/down from their.
```json
{ "command": "visual_move_page", "args": {"forward": true} }
{ "command": "visual_move_page", "args": {"forward": false} }
```
Pressing pageup/pagedown moves caret up/down by one page, from its current
position even if it is far way from currently visible viewport, which may
cause unexpected visual scrolling.
"""
def run(self, edit, forward=True):
sels = self.view.sel()
visible_region = self.view.visible_region()
if len(sels) == 1 and sels[0] not in visible_region:
first_row, _ = self.view.rowcol(visible_region.begin())
last_row, _ = self.view.rowcol(visible_region.end())
centered_row = int((first_row + last_row) / 2)
centered_pt = self.view.text_point(centered_row, 0)
# adjust caret position
self.view.sel().clear()
self.view.sel().add(centered_pt)
# call normal page up/down command
self.view.run_command("move", {"by": "pages", "forward": forward})
Packages/User/Default.sublime-keymap
[
{
"keys": ["pageup"],
"command": "visual_move_page", "args": { "forward": false }
},
{
"keys": ["pagedown"],
"command": "visual_move_page", "args": { "forward": true }
},
]
Hi there, thanks for all that. Sorry to have been rude and angry; as I’m having difficulty now reproducing the problem there’s a good chance it was unwarranted, so I’ve edited my posts to be milder. So I’ll just keep an eye out for the problem and when it happens again I’ll come back here and inspect your answer more carefully. In the meantime, the only thing I can reliably make it do that resembles the problem is to go [ctrl+home] and then [page-down], and this will take me only half-a-page down because I guess the caret just goes to the middle of the page.