jesseduffield
Scrolling with `C-{d,u}` should move the cursor line
Is your feature request related to a problem? Please describe.
When you scroll with C-{d,u} the cursor line doesn't follow the scroll position.
Describe the solution you'd like It should follow the scroll position, just like vim. Selecting lines will be easier this way.
I don't agree, I think c-d/c-u should behave like scrolling with the wheel, which does not change the selection (and shouldn't).
If you want to change the selection, why not just use up/down-arrow?
Scrolling with the wheel also changes the selected line on vim. I suppose for people who don't know/use vim, this is a more "natural" behavior. But a config option to modify this behavior would be nice.
If you want to change the selection, why not just use up/down-arrow?
One scrolls the panel (which can be configured with scrollHeight), and one moves the selection. When the selection line hits the bottom of the page, it will incidentally scroll the page in a very slow way, but this is a very tedious means of page navigation.
Imagine roughly eyeballing through the diff using C-{d,u}, finding the line you want, then having to hold down {j,k} as you wait for the page to slowly scroll from the beginning towards the line you found for the second time.
Along with https://github.com/jesseduffield/lazygit/pull/2227, this kind of feature would make lazygit more comfortable to use for users who are used to vim.
Scrolling with the wheel also changes the selected line on vim.
In my version of vim, the wheel seems to be bound to up/down arrow. In other words, it doesn't scroll at all, it only moves the cursor; only when the cursor reaches the edge of the viewport does it scroll the window, to keep the cursor visible. This is very unusual behavior for a GUI application, I would very much like lazygit to not adopt this behavior.
I suppose for people who don't know/use vim, this is a more "natural" behavior.
In the windowing systems that I am familiar with (macOS and Windows), the scroll wheel only moves the viewport and does nothing else. It doesn't change the selection. I find it natural for lazygit to behave the same. (Right now it doesn't always: for list views, it changes the selection as soon as it would otherwise leave the visible portion of the window. I find this annoying and have just posted a PR that "fixes" this: #2608.)
If you want to change the selection, why not just use up/down-arrow?
When the selection line hits the bottom of the page, it will incidentally scroll the page in a very slow way, but this is a very tedious means of page navigation.
This is interesting; I am about to post another PR soon that changes this behavior slightly. Right now, when the selection hits the bottom of the page, it only scrolls by one line, and I'm changing this to scroll by half a page to put the selection in the middle of the window. I wonder if this would already help some. (Maybe not enough.)
Imagine roughly eyeballing through the diff using
C-{d,u}, finding the line you want, then having to hold down{j,k}as you wait for the page to slowly scroll from the beginning towards the line you found for the second time.
OK, I see. Maybe I'm not the best one to comment on this; I'm a laptop user, and I usually scroll with two fingers on the trackpad. If I found the line I want, I just click it. That's very easy and comfortable because I have my finger on the trackpad anyway; but I realize that for desktop users with mouse and keyboard the situation is different, since you probably want to avoid having to reach for the mouse.
With all that said, I personally don't care whether or how we change the behavior of C-{d,u} as I don't use it at all. If it makes sense for it to behave differently than scrolling with the wheel, for those who use them, then that's fine with me. I do feel strongly that we shouldn't change the behavior of the wheel, though.
Imagine roughly eyeballing through the diff using
C-{d,u}, finding the line you want, then having to hold down{j,k}as you wait for the page to slowly scroll from the beginning towards the line you found for the second time.OK, I see. Maybe I'm not the best one to comment on this; I'm a laptop user, and I usually scroll with two fingers on the trackpad. If I found the line I want, I just click it. That's very easy and comfortable because I have my finger on the trackpad anyway; but I realize that for desktop users with mouse and keyboard the situation is different, since you probably want to avoid having to reach for the mouse.
I'd like to suggest an alternative option. Bind C-f C-b. Have it move cursor by default.
I admit, if you do this then it suggests C-u C-d should also use cursor by default. Why should they differ? Especially the one that scrolls more. If anything, C-u C-d should move cursor and the other not for skimming, but I wouldn't vote for that.
To get to the root of the problem, the question becomes, "When would you want C-u C-d to not move the cursor?" My answer is never, but I'd like to hear use cases.
Navigating using keyboard only is a main selling point for Vim. Using mouse or holding down arrows or jk is not very VimGolf. Not being able to navigate diffs properly is moving me away from this tool. Especially after running into the exact problem quoted. I'd be very happy to have these bindings modified and added.
