You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I like the sound of ctrl+pgup/pgdown. If that's actually a thing that we can send to the terminal then I'm on board.
f and b are already used for various keybindings so I'm hesitant to use those.
I'll chuck a good-first-issue label on this. If anybody wants to take a stab, you can search for scrollUpMain in the codebase to see how that works. We need versions of scrollUpView and scrollDownView in pkg/gui/global_handlers.go that take the scroll amount as a parameter, rather than hardcoding to use gui.UserConfig.Gui.ScrollHeight internally. Then we can pass them the height of the view as that parameter to have us scrolling by a whole page.
Tbh I mainly solved this by just setting scroll amount to 10 in config instead of the default of 2 and using the mouse wheel to scroll, so this can be closed if you want.
Based on my understanding of #1707 (comment) I have created a PR to try and implement this -> #1709
I had to use Alt+f to scroll up a page and Alt+b to scroll down a page since I was not able to figure out how to use other modifiers like Shift or Ctrl
@sdegutis I'm fairly critical of Go to be honest. I've had enough exposure to Rust to feel that Go is sorely lacking in features. Especially when it comes to code re-use, Go just doesn't have much (if anything) to offer due to lack of both inheritance, mixins/traits, and generics (though generics are on the way). I've done a fairly extensive writeup on my thoughts here
@glendsoza Nice one. I've left a comment on that PR. As commented, there's another PR in flight that's going to make it easier to use shift/ctrl modifiers, and hopefully that'll let us use pgdown/pgup.
@jesseduffield I agree, I came to that conclusion maybe 7 years ago. I tried Rust out and I guess it's fine if you need low-level and lightning-fast and ultra-safe code, which I do 0% of the time (and apparently neither does VS Code but it works well enough). I'm going to try my hand at a quick Electron git client in TypeScript one of these days using simple-git.
I also vote for hotkeys for whole page scrolling. C-f/C-b (like manpage) and C-u/C-d (like tig) both feels right to me. It should be configurable so there should just be a default one and let users choose what they like.
Reacted by Sean Matheson, kerugma, Silouan Wright, Martin Krauskopf, Oleh Vanin, Magnus, wardw, Matt, Mohit Sakhuja and Benjamin
As of v0.50 you can now focus the main view (by pressing 0), and then you can navigate it using all the normal navigation keys like . and , for scrolling by page, or < and > for beginning/end.
Reacted by WilliamLv, Daniel Jonsson, goyalyashpal, Simon Chester, Matt, Julian Keenaghan and Ivan Nikulin
Given that we do now have a way of scrolling the main view both by line and by page via focusing it, I wonder if we should update the page-up/page-down keys to actually scroll by page now. Seems like lots of people are surprised that it currently defaults to only scrolling by line.
On the other hand, lots of lazygit users (myself included) have become accustomed to page-up/page-down only scrolling by lines
@jesseduffield In this comment you only talk about scrolling by line vs. scrolling by page, but isn't the bigger difference which view they operate on? I'd expect pgup/pgdown to scroll the current view (by page of course, not by line), not the main view. They would then do exactly the same as , and ., in the same way as home and end do the same as < and >.
This change makes a lot of sense to me, and I'm in favor. We still have two other ways of scrolling the main view (ctrl-d/u and J/K; they are both listed in the keybinding cheat sheets, but are otherwise not very discoverable).
But I'm probably not qualified to judge, because I rarely use the keyboard to scroll the main view; I use two fingers on the trackpad for that.
As a vim user, I'm accustomed to ctrl+u and ctrl+d scrolling by half pages, and that is what I expected in the lazygit diff view (instead, it scrolls one line, just like pg up/dn). I'm very much in favor of making these scroll by page in the diff view.
When I'm staging files for a commit, I'd like to quickly move from file to file, while being able to scroll quickly in the diff without having to switch focus back and forth between the panes.
Ideally, scrolling by line should also be available somehow in this view. One suggestion would be to use ctrl+e and ctrl+y to scroll by line, just like in vim, however, I see that ctrl+e is already in use. ctrl+j and ctrl+k could also be agreeable, and seems to be available.
I think a modifier + any-navigation keys applying to the current view would be good.
ctrl + , or ctrl + . applying to current view would be great. I also think we should have an alternative for line scrolling on the current view, page-up/down should really do what they say on the box imo.
... I should really offer a PR rather than my opinion
As of v0.50 you can now focus the main view (by pressing 0), and then you can navigate it using all the normal navigation keys like . and , for scrolling by page, or < and > for beginning/end.
for now is there a workaround that we can do in the configuration? I would be happy if simply pageup and pagedown in their current implementation have a configurable number of lines that will scroll . is that configurable?
or maybe there is a a way to bind a new key to behave like ,. in my (eg) "unstaged changes" frame?
I wonder if we should update the page-up/page-down keys to actually scroll by page now. Seems like lots of people are surprised that it currently defaults to only scrolling by line.
I think that this is how it should be implemented. Ctrl+pgup/down is unnecessary and awkward as well. It confounded me to see that PgUp/PgDn simply scroll and,/. scroll pages. There seem to be a million ways to scroll the screen, not sure why the PgUp/PgDn buttons were chosen to also do this. Users will definitely not expect this, except, ofc, longtime users who are already used to the current misnomer :) Luckily, I was able to change it easily via the config.
Supporting this — I checked the source and the pane size is already known at runtime (ViewTrait.PageDelta() = InnerHeight()-1 in pkg/gui/context/view_trait.go). The gap is only that scrollUpMain/scrollDownMain hardcode Gui.ScrollHeight (default 2, user_config.go) with no bindable page-scroll-main action. So this doesn't need config-side size detection, just the parameterized scroll actions described above, bound to ctrl+pgup/pgdn.
Activity
jesseduffield commentedon Jan 20, 2022
I like the sound of ctrl+pgup/pgdown. If that's actually a thing that we can send to the terminal then I'm on board.
f and b are already used for various keybindings so I'm hesitant to use those.
I'll chuck a good-first-issue label on this. If anybody wants to take a stab, you can search for
scrollUpMainin the codebase to see how that works. We need versions ofscrollUpViewandscrollDownViewinpkg/gui/global_handlers.gothat take the scroll amount as a parameter, rather than hardcoding to usegui.UserConfig.Gui.ScrollHeightinternally. Then we can pass them the height of the view as that parameter to have us scrolling by a whole page.jesseduffield commentedon Jan 20, 2022
btw @sdegutis if you want to get your hands dirty with Go, this would be a good first start!
sdegutis commentedon Jan 20, 2022
Sorry, to clarify, I'm requesting we use Shift-PageUp and Shift-PageDown (or Ctrl-).
sdegutis commentedon Jan 20, 2022
Tbh I mainly solved this by just setting scroll amount to 10 in config instead of the default of 2 and using the mouse wheel to scroll, so this can be closed if you want.
sdegutis commentedon Jan 21, 2022
By the way @jesseduffield when I looked through the src earlier, I was surprised this was written in Go. I assumed it was written using https://www.npmjs.com/package/blessed
jesseduffield commentedon Jan 21, 2022
Happy to keep this issue open as others have asked about it (even I would like it haha).
Yeah my choice to use Go was really just coincidence because I wanted to learn the language
sdegutis commentedon Jan 21, 2022
So how do you like Go after learning it?
glendsoza commentedon Jan 21, 2022
First of all Awesome tool!
Based on my understanding of #1707 (comment) I have created a PR to try and implement this -> #1709
I had to use
Alt+fto scroll up a page andAlt+bto scroll down a page since I was not able to figure out how to use other modifiers likeShiftorCtrljesseduffield commentedon Jan 23, 2022
@sdegutis I'm fairly critical of Go to be honest. I've had enough exposure to Rust to feel that Go is sorely lacking in features. Especially when it comes to code re-use, Go just doesn't have much (if anything) to offer due to lack of both inheritance, mixins/traits, and generics (though generics are on the way). I've done a fairly extensive writeup on my thoughts here
@glendsoza Nice one. I've left a comment on that PR. As commented, there's another PR in flight that's going to make it easier to use shift/ctrl modifiers, and hopefully that'll let us use pgdown/pgup.
sdegutis commentedon Jan 23, 2022
@jesseduffield I agree, I came to that conclusion maybe 7 years ago. I tried Rust out and I guess it's fine if you need low-level and lightning-fast and ultra-safe code, which I do 0% of the time (and apparently neither does VS Code but it works well enough). I'm going to try my hand at a quick Electron git client in TypeScript one of these days using simple-git.
zhengpd commentedon May 1, 2022
I also vote for hotkeys for whole page scrolling.
C-f/C-b(like manpage) andC-u/C-d(like tig) both feels right to me. It should be configurable so there should just be a default one and let users choose what they like.mattavos commentedon May 8, 2025
@jesseduffield -- any update on this one? It'd be really lovely to be able to scroll by whole pages.
stefanhaller commentedon May 8, 2025
As of v0.50 you can now focus the main view (by pressing
0), and then you can navigate it using all the normal navigation keys like.and,for scrolling by page, or<and>for beginning/end.jesseduffield commentedon May 8, 2025
Given that we do now have a way of scrolling the main view both by line and by page via focusing it, I wonder if we should update the page-up/page-down keys to actually scroll by page now. Seems like lots of people are surprised that it currently defaults to only scrolling by line.
On the other hand, lots of lazygit users (myself included) have become accustomed to page-up/page-down only scrolling by lines
stefanhaller commentedon May 9, 2025
@jesseduffield In this comment you only talk about scrolling by line vs. scrolling by page, but isn't the bigger difference which view they operate on? I'd expect pgup/pgdown to scroll the current view (by page of course, not by line), not the main view. They would then do exactly the same as
,and., in the same way as home and end do the same as<and>.This change makes a lot of sense to me, and I'm in favor. We still have two other ways of scrolling the main view (ctrl-d/u and J/K; they are both listed in the keybinding cheat sheets, but are otherwise not very discoverable).
But I'm probably not qualified to judge, because I rarely use the keyboard to scroll the main view; I use two fingers on the trackpad for that.
otytlandsvik commentedon May 9, 2025
As a vim user, I'm accustomed to
ctrl+uandctrl+dscrolling by half pages, and that is what I expected in the lazygit diff view (instead, it scrolls one line, just like pg up/dn). I'm very much in favor of making these scroll by page in the diff view.When I'm staging files for a commit, I'd like to quickly move from file to file, while being able to scroll quickly in the diff without having to switch focus back and forth between the panes.
Ideally, scrolling by line should also be available somehow in this view. One suggestion would be to use
ctrl+eandctrl+yto scroll by line, just like in vim, however, I see thatctrl+eis already in use.ctrl+jandctrl+kcould also be agreeable, and seems to be available.hacker-DOM commentedon May 9, 2025
We could also scroll alternative views by alt+down/up or ctrl+down/up
pstefa1707 commentedon Jun 3, 2025
I think a modifier + any-navigation keys applying to the current view would be good.
ctrl + ,orctrl + .applying to current view would be great. I also think we should have an alternative for line scrolling on the current view, page-up/down should really do what they say on the box imo.... I should really offer a PR rather than my opinion
DanOpcode commentedon Jun 30, 2025
Thanks, that's perfect!
goyalyashpal commentedon Jul 14, 2025
i think that the current keybind of lazygit (
0.52) is fine:,.: single page (comma, dot)<>: top/bottom (less/greater than;S-,/S-.)kj: single lineUP/DN: single line (arrows)PGUP/PGDN: main pane single line (page-up / page-down)C-u/d: main pane single line (i don't use) (ctrl-u / ctrl-d)i am using workman layout, and not vim.
so, forcing legacy vim needlessly in my throat would very well be an unpleasant change.
KJ7LNW commentedon Aug 3, 2025
for now is there a workaround that we can do in the configuration? I would be happy if simply pageup and pagedown in their current implementation have a configurable number of lines that will scroll . is that configurable?
or maybe there is a a way to bind a new key to behave like
,.in my (eg) "unstaged changes" frame?sysoleg commentedon Aug 10, 2025
@KJ7LNW
KJ7LNW commentedon Aug 10, 2025
awesome, now it just needs to be configurable as a % of viewport height!
rpgdev commentedon Aug 20, 2026
I think that this is how it should be implemented. Ctrl+pgup/down is unnecessary and awkward as well. It confounded me to see that PgUp/PgDn simply scroll and
,/.scroll pages. There seem to be a million ways to scroll the screen, not sure why the PgUp/PgDn buttons were chosen to also do this. Users will definitely not expect this, except, ofc, longtime users who are already used to the current misnomer :) Luckily, I was able to change it easily via the config.HaleTom commentedon Oct 24, 2026
Supporting this — I checked the source and the pane size is already known at runtime (
ViewTrait.PageDelta()=InnerHeight()-1inpkg/gui/context/view_trait.go). The gap is only thatscrollUpMain/scrollDownMainhardcodeGui.ScrollHeight(default 2,user_config.go) with no bindable page-scroll-main action. So this doesn't need config-side size detection, just the parameterized scroll actions described above, bound to ctrl+pgup/pgdn.