Skip to content

Moving the cursor when scrolling in the history to select text #4985

Closed

Description

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)

Activity

  1. added
    Issue-FeatureComplex enough to require an in depth planning process and actual budgeted, scheduled work.
    on Mar 18, 2020
  2. ghost added
    Needs-Tag-FixDoesn't match tag requirements
    on Mar 18, 2020
  3. ghost added
    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting
    on Mar 18, 2020
  4. zadjii-msft commented on Mar 18, 2020

    @zadjii-msft
    Member

    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.

  5. added
    Area-TerminalControlIssues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.)
    Issue-TaskIt's a feature request, but it doesn't really need a major design.
    and removed
    Issue-FeatureComplex enough to require an in depth planning process and actual budgeted, scheduled work.
    on Mar 18, 2020
  6. ghost removed
    Needs-Tag-FixDoesn't match tag requirements
    on Mar 18, 2020
  7. fullenw1 commented on Mar 18, 2020

    @fullenw1
    Author

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

  8. zadjii-msft commented on Mar 18, 2020

    @zadjii-msft
    Member

    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

  9. fullenw1 commented on Mar 18, 2020

    @fullenw1
    Author

    Ah ok :)
    Sorry for the misunderstanding!

  10. carlos-zamora commented on Mar 18, 2020

    @carlos-zamora

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

  11. 3 remaining items

  12. carlos-zamora commented on Jun 28, 2022

    @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

  13. ghost added
    Needs-Tag-FixDoesn't match tag requirements
    on Jun 28, 2022
  14. ghost removed
    Needs-Tag-FixDoesn't match tag requirements
    on Jul 20, 2022
  15. carlos-zamora commented on Jul 20, 2022

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

  16. zadjii-msft commented on Aug 21, 2024

    @zadjii-msft
    Member
  17. carlos-zamora commented on Aug 21, 2024

    @carlos-zamora

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Area-TerminalControlIssues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.)Issue-TaskIt's a feature request, but it doesn't really need a major design.Needs-Tag-FixDoesn't match tag requirementsProduct-TerminalThe new Windows Terminal.

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions