-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Conversation
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
There was a problem hiding this 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
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. |
Chill, msftbot. @carlos-zamora is still out until Monday. |
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. |
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. |
(I'm sure I have more to do but this is a shot in the dark at progress haha)
What's left:
|
After updating the branch, ran into a huge problem. It's similar to #6431. When a 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? |
Offline discussion w/ @zadjii-msft to get around the win32 input mode issue:
That'll be done in the upcoming commit |
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. |
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 😕 |
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>
Just FYI this still needs a rebase, and is becoming increasingly out of sync |
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. |
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
Detailed Description of the Pull Request / Additional comments
The
enum Direction
got moved fromTermApp
toTerminalSettings
. This exposes theenum
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 theDirection
(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.