Moving the cursor when scrolling in the history to select text

[fullenw1]

Description of the new feature/enhancement

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.

Proposed technical implementation details (optional)

[zadjii-msft]

@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]

@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]

Oh I mostly meant that @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]

Ah ok :)
Sorry for the misunderstanding!

[carlos-zamora]

I'll leave this open for now. I want to make sure I update the spec. Thanks!

[DHowett-MSFT]

@carlos-zamora I pulled triage off this; can you link it up to the main issue you're using to track these things, in Mike's checklist style?

[carlos-zamora]

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.

Closed by #10824

[carlos-zamora]

From #13533...

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 :/

[zadjii-msft]

@carlos-zamora did we do this?

[carlos-zamora]

Yeah, I'm gonna close this out. We're able to select text using the keyboard and move the viewport around.