Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement keybindings to quick edit selection #3758

Closed
wants to merge 20 commits into from

Conversation

carlos-zamora
Copy link
Member

@carlos-zamora carlos-zamora commented Nov 28, 2019

Summary of the Pull Request

Adds the moveSelectionPoint keybinding, which allows you to modify an existing selection using the keyboard. It has the following parameters:

  • direction: up | down | left | right
  • expansionMode: cell | word | viewport | buffer

What's next for keyboard selection:

References

Spec: #2840
#715 (does not close, but does most of the work for it)

This is going to work really cool with #2989

PR Checklist

  • Closes #XXX
  • CLA signed.
  • Tests added/passed
  • Requires documentation to be updated
  • I am a core contributor

Detailed Description of the Pull Request / Additional comments

The enum Direction got moved from TermApp to TerminalSettings. This exposes the enum everywhere and makes it easier to pass it down to the terminal control.

The design is pretty straightforward, actually. It's just a switch-case statement for the SelectionExpansionMode (expansionMode). That just calls the appropriate function, which is another switch-case statement for the Direction (direction).

The enum SelectionTarget was added in preparation for Mark Mode.

Validation Steps Performed

Currently just did tests on my own. Unit tests for selection will be added.

Add first draft of functionality for updating selection
# Conflicts:
#	src/cascadia/TerminalApp/ActionArgs.cpp
#	src/cascadia/TerminalApp/ActionArgs.h
#	src/cascadia/TerminalApp/ActionArgs.idl
#	src/cascadia/TerminalApp/AppKeyBindingsSerialization.cpp
#	src/cascadia/TerminalApp/Pane.h
#	src/cascadia/TerminalApp/ShortcutActionDispatch.h
#	src/cascadia/TerminalApp/TerminalPage.h
@zadjii-msft zadjii-msft added Area-Settings Issues related to settings and customizability, for console or terminal Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Product-Terminal The new Windows Terminal. labels Dec 16, 2019
Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd approve this, but I think the Direction/SelectionExpansionMode enums could be unified. If it can't be, I'll approve this

src/cascadia/TerminalApp/ActionArgs.h Show resolved Hide resolved
src/cascadia/TerminalCore/Terminal.hpp Outdated Show resolved Hide resolved
src/cascadia/TerminalControl/TermControl.cpp Outdated Show resolved Hide resolved
src/cascadia/TerminalCore/TerminalSelection.cpp Outdated Show resolved Hide resolved
@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jan 3, 2020
@ghost ghost added the No-Recent-Activity This issue/PR is going stale and may be auto-closed without further activity. label Jan 10, 2020
@ghost
Copy link

ghost commented Jan 10, 2020

This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.

@miniksa miniksa removed the No-Recent-Activity This issue/PR is going stale and may be auto-closed without further activity. label Jan 10, 2020
@miniksa
Copy link
Member

miniksa commented Jan 10, 2020

Chill, msftbot. @carlos-zamora is still out until Monday.

@zadjii-msft zadjii-msft added this to the Terminal v0.9 milestone Jan 16, 2020
@ghost ghost added the No-Recent-Activity This issue/PR is going stale and may be auto-closed without further activity. label Jan 23, 2020
@ghost
Copy link

ghost commented Jan 23, 2020

This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.

@ghost ghost removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something No-Recent-Activity This issue/PR is going stale and may be auto-closed without further activity. labels Jan 24, 2020
@carlos-zamora
Copy link
Member Author

I'm away from my dev box at the moment, so no surprise the build is failing. I'll actually fix things when I get back to the office. For now just making progress on the PR fixes and making sure this PR doesn't get auto-closed by the bot.

Carlos Zamora and others added 4 commits January 24, 2020 13:44
(I'm sure I have more to do but this is a shot in the dark at progress haha)
@carlos-zamora
Copy link
Member Author

carlos-zamora commented Jan 28, 2020

What's left:

  • Update schema properly
  • Bug:
    • Repro:
      • double click on word
      • move selection anchor with keyboard by one cell onto next word
      • next word is selected
    • Expected:
      • next cell is selected
    • EDIT: This was fixed in one of the refactors leading up to v1.
  • Terminal Core Testing

@carlos-zamora
Copy link
Member Author

After updating the branch, ran into a huge problem. It's similar to #6431. When a MoveSelectionPoint keybinding comes in, the key down event is handled properly and runs the logic for moving the selection point. The problem is, the key up event is not handled by the keybinding, but it's still sent in Win32 Input Mode (#6309). This results in the selection being cleared on key up...

I'm not too sure on what the right move here is. Maybe we need to keep track of which key down events are handled as keybindings, and suppress the following key up event?

@carlos-zamora
Copy link
Member Author

Offline discussion w/ @zadjii-msft to get around the win32 input mode issue:

  • if the key chord triggered a keybinding action, suppress the key up event
  • to do this, in TermControl, if _TryHandleKeyBinding was successful, cache the pressed key chord, and suppress the upcoming key up event for this key chord

That'll be done in the upcoming commit

@ofek
Copy link
Contributor

ofek commented Dec 1, 2020

Other than a rebase, are there any other blockers for this?

@carlos-zamora
Copy link
Member Author

Other than a rebase, are there any other blockers for this?

Aside from the rebase, the main blocker was that the selection would be cleared on a KeyUp event (obviously something we don't want haha). Since it's been open for so long, this PR could probably use a bit of polish as a part of the rebase? Not sure.

@zadjii-msft
Copy link
Member

I'm pretty sure it's just blocked on the bureaucratic approval of the spec (#2840), and us having enough time to actually loop back on this one. We'd need to double-check that this matches the latest state of the spec. We've mostly been bogged down in other areas of the project. I too wish we had the engineering resources to finish this one off, but alas 🤷‍♂️ beyond just finishing merging this, we'd need to have someone ready to handle issues that might come up during selfhost before release, and we're all-hands-on-other-decks at the moment 😕

@zadjii-msft zadjii-msft mentioned this pull request Dec 15, 2020
6 tasks
ghost pushed a commit that referenced this pull request Feb 18, 2021
This PR is a resurrection of #8522. @Hegunumo has apparently deleted
their account, but the contribution was still valuable. I'm just here to
get it across the finish line.

This PR adds new action for navigating to the next & previous search
results. These actions are unbound by default. These actions can be used
from directly within the search dialog also, to immediately navigate the
results. 

Furthermore, if you have a search started, and close the search box,
then press this keybinding, _it will still perform the search_. So you
can just hit <kbd>F3</kbd> repeatedly with the dialog closed to keep
searching new results. Neat!

If you dispatch the action on the key down, then dismiss a selection on
a key up, we'll end up immediately destroying the selection when you
release the bound key. That's annoying. It also bothers @carlos-zamora
in #3758. However, I _think_ we can just only dismiss the selection on a
key up. I _think_ that's fine. It _seems_ fine so far. We've got an
entire release cycle to futz with it.

## Validation Steps Performed
I've played with it all day and it seems _crisp_.

Closes #7695 

Co-authored-by: Kiminori Kaburagi <yukawa_hidenori@icloud.com>
@ofek
Copy link
Contributor

ofek commented Mar 18, 2021

Just FYI this still needs a rebase, and is becoming increasingly out of sync

@zadjii-msft
Copy link
Member

Yep, it sure is - we're still bogged down with some other priorities. I'll leave it up to @carlos-zamora if he wants to just leave this open for now, or close and re-open when we come back to this (in a few months probably)

@carlos-zamora
Copy link
Member Author

Yep, it sure is - we're still bogged down with some other priorities. I'll leave it up to @carlos-zamora if he wants to just leave this open for now, or close and re-open when we come back to this (in a few months probably)

I'm just gonna outright close this. We need to revisit the specs anyways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Settings Issues related to settings and customizability, for console or terminal Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants