Add <C-e> and <C-y> to scroll one line at a time #4977
Conversation
stacyharper
force-pushed
the
scroll
branch
3 times, most recently
from
89e1c4c to
8c02387
Compare
src/context.hh
Outdated
| class AliasRegistry; | ||
|
|
||
| enum Direction { Backward = -1, Forward = 1 }; | ||
| enum Velocity { FullScreen = 0, HalfScreen = 1, Line = 2 }; |
There was a problem hiding this comment.
"Velocity" is defined as "the speed of something in a given direction". I think "distance" would be a better name here.
There was a problem hiding this comment.
Fair enough, I renamed this. Thanks!
|
I just rebased this. Could this be reviewed again? |
|
The implementation looks fine, but I am wondering if we need to dedicate yet another binding to this. Would it be okay to rely on passing a line count to another command (say |
|
imo |
|
I do agree with it would be more consistent, but we already have a binding for scrolling page by page, then a binding for scrolling half page by half page, and now we want one for scrolling line by line. I think this is too many mappings for this and would like to get some consolidation. Especially as this is on top of a whole set of other mappings in view mode. Another direction would be to say that this is a view command and we should have a way to decide how the cursor should behave. An idea that comes to mind is to have say |
I don't share your opinion on if it is too many mapping or not. To me there is 3 distinct way to scroll the buffer, and they are very common, and present on other softwares. Plus we managed to refactorise the code, to avoid creating too many functions for them. Do you fear about missing available shortcuts?
I'm not sure to fully understand what you propose here. You mean to add a dedicated mode, that offer different ways to scroll? And the users could map a shortcut to this if they want to? ( But anyway, imo we still need an internal command to scroll one line, that respect the behavior I've mentioned in the body here. |
Recently I noticed changes with the behavior of my keybinds: map global normal <C-e> vj map global normal <C-y> vk This is because the cursor movement behavior changed with vj and vk. Scrolling window was previously blocked by the cursor. Now the cursor and selection stays in place. I think the view keyboard behaviors are consistent, and coherent with the current state. But this isn't exactly what we want from <C-e> and <C-y>. Example, when you start to scroll with <C-e> (your cursor stay in place), then you press <C-d> (your cursor is moved back to your view). Example, when you start to scroll with <C-e> (your cursor stay in place), then you press j or k (your view is pushed back to initial position). To solve this, I think we need news and differents default keybinds <C-e> and <C-y>.
3 participants
Recently I noticed changes with the behavior of my keybinds:
This is because the cursor movement behavior changed with vj and vk. Scrolling window was previously blocked by the cursor. Now the cursor and selection stays in place.
I think the view keyboard behaviors are consistent, and coherent with the current state. But this isn't exactly what we want from
<C-e>and<C-y>.Example, when you start to scroll with
<C-e>(your cursor stay in place), then you press<C-d>(your cursor is moved back to your view).Example, when you start to scroll with
<C-e>(your cursor stay in place), then you pressjork(your view is pushed back to initial position).To solve this, I think we need news and differents default keybinds
<C-e>and<C-y>.