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
{{ message }}
Repository navigation
Moving the cursor when scrolling in the history to select text #4985
Currently we can scroll up and down in the history with the keyboard but the cursor remains at the bottom.
That's why, when we want to copy/paste something from the history we have to use the mouse.
The idea is that when we scroll up and down with the keyboard, the cursor is following.
Also once the cursor is inside the history, we can move right and left with the keyboard to select the text we need.
Carlos Zamora (@carlos-zamora) this sounds like a good idea to include as part of the #715/#2840 spec. I'll leave it to you if you want to leave this open or merge it in with that one.
Mike Griese (@zadjii-msft)
Oh yes! I've searched before opening this issue but probably not with the right keywords...
You can merge to either of them. I never merged an issue, but I think I don't have permissions to do that. Can you do it for me please? Or just guide me :)
Oh I mostly meant that Carlos Zamora (@carlos-zamora) should be the one to merge it. He might want to leave this open as a child task on that issue - sometimes we'll do that for larger features that comprise a bunch of smaller tasks. Since he owns this whole feature area, I'm leaving the decision up to him
Ok, now that a good amount of mark mode and keyboard selection is done, we (will) have support for the following navigation schemes:
*arrow keys --> move by character
ctrl + arrow keys --> move by word
home/end --> move to start/end of line
*ctrl + home/end --> move to start/end of buffer
*pgup/pgdn --> scroll up/down by viewport size
If you hit a viewport boundary, we automatically scroll.
The ask here is that the scroll key bindings automatically move the cursor and force it to be within the viewport. But I think the starred (*) items above may be sufficient to address the issue. I also think there's still a use case for keyboard scrolling without moving the cursor.
So I'm going to close this out, but I'm open to discussing it more if I'm missing something.
The "mark" should follow the scroll buffer if the buffer is scrolled via other actions. Ideally, it should select when that happens with SHIFT pressed.
Design-wise, I'm thinking of it this way:
If no selection has been made, scrolling clamps the cursor to be within the visible area.
If a selection has been made, scrolling doesn't move the cursor.
Why not drag/clamp the active endpoint? Because there's still a benefit to scrolling without forcing the endpoint to move with you. That's how text editors generally work, so it's kinda the expected behavior here, right?
In order to accomplish that, I think we need to wait for #13516 because the "single cell selection" means that there's always a selection :/
Activity
zadjii-msft commentedon Mar 18, 2020
Carlos Zamora (@carlos-zamora) this sounds like a good idea to include as part of the #715/#2840 spec. I'll leave it to you if you want to leave this open or merge it in with that one.
fullenw1 commentedon Mar 18, 2020
Mike Griese (@zadjii-msft)
Oh yes! I've searched before opening this issue but probably not with the right keywords...
You can merge to either of them. I never merged an issue, but I think I don't have permissions to do that. Can you do it for me please? Or just guide me :)
zadjii-msft commentedon Mar 18, 2020
Oh I mostly meant that Carlos Zamora (@carlos-zamora) should be the one to merge it. He might want to leave this open as a child task on that issue - sometimes we'll do that for larger features that comprise a bunch of smaller tasks. Since he owns this whole feature area, I'm leaving the decision up to him
fullenw1 commentedon Mar 18, 2020
Ah ok :)
Sorry for the misunderstanding!
carlos-zamora commentedon Mar 18, 2020
I'll leave this open for now. I want to make sure I update the spec. Thanks!
3 remaining items
carlos-zamora commentedon Jun 28, 2022
Ok, now that a good amount of mark mode and keyboard selection is done, we (will) have support for the following navigation schemes:
If you hit a viewport boundary, we automatically scroll.
The ask here is that the scroll key bindings automatically move the cursor and force it to be within the viewport. But I think the starred (*) items above may be sufficient to address the issue. I also think there's still a use case for keyboard scrolling without moving the cursor.
So I'm going to close this out, but I'm open to discussing it more if I'm missing something.
Closed by #10824
carlos-zamora commentedon Jul 20, 2022
From #13533...
Design-wise, I'm thinking of it this way:
In order to accomplish that, I think we need to wait for #13516 because the "single cell selection" means that there's always a selection :/
zadjii-msft commentedon Aug 21, 2024
Carlos Zamora (@carlos-zamora) did we do this?
carlos-zamora commentedon Aug 21, 2024
Yeah, I'm gonna close this out. We're able to select text using the keyboard and move the viewport around.