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.

Sign up for GitHub

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

Jump to bottom

Mark Mode: Toggle instead of holding shift #3663

Closed
carlos-zamora opened this issue Nov 22, 2019 · 2 comments · Fixed by #13370
Closed

Mark Mode: Toggle instead of holding shift #3663

carlos-zamora opened this issue Nov 22, 2019 · 2 comments · Fixed by #13370
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone
22H1

Comments

@carlos-zamora
Copy link
Member

Have you considered following tmux's implementation of this feature? It has the benefit of being well-known, and it won't step on tmux's own implementation as long as the key combination to activate it doesn't coincide with tmux's

Here's a little guide that explains how that works:
http://www.rushiagr.com/blog/2016/06/16/everything-you-need-to-know-about-tmux-copy-pasting-ubuntu/

Originally posted by @fpqc in #2840

The main idea here (I think) is rather than holding the shift key to switch anchors, you just toggle which selection anchor you're moving.

Off the top of my head, I'm not sure how to make it not conflict with the existing implementation of mark mode, but I'm interested 😊
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Nov 22, 2019
@carlos-zamora carlos-zamora mentioned this issue Nov 22, 2019
Merged
@carlos-zamora carlos-zamora added Area-Interaction Interacting with the vintage console window (as opposed to driving via API or hooks) Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal. and removed Needs-Tag-Fix Doesn't match tag requirements labels Nov 22, 2019
@DHowett-MSFT DHowett-MSFT removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Nov 25, 2019
@carlos-zamora
Copy link
Member Author

This should be a part of the #4993 scenario.

@zadjii-msft zadjii-msft added Area-Input Related to input processing (key presses, mouse, etc.) and removed Area-Interaction Interacting with the vintage console window (as opposed to driving via API or hooks) labels Jul 7, 2020
@zadjii-msft zadjii-msft modified the milestones: Terminal v2.0, 22H1 Jan 4, 2022
@zadjii-msft zadjii-msft mentioned this issue Mar 14, 2022
Open
11 tasks
@carlos-zamora carlos-zamora mentioned this issue May 6, 2022
Merged
2 tasks
ghost pushed a commit that referenced this issue May 6, 2022
@carlos-zamora
Add ability to select all text in the buffer (#13045)
60a4837 
Adds the `selectAll` action which can be used to select all text in the buffer (regardless of whether a selection is present).

## References
#3663 - Mark Mode
#4993 - [Scenario] Keyboard selection

## PR Checklist
* [x] Closes #1469
* [x] Tests added/passed

## Detailed Description of the Pull Request / Additional comments
I've made it such that selecting the "entire buffer" really just selects up to the mutable viewport. This seems like a nice QOL improvement since there's generally nothing past that.

When the user selects all, the viewport does not move. This is consistent with CMD behavior and is intended to allow the user to not lose context when selecting everything.

A minor change had to be made to the DxRenderer because this uncovered an underflow issue. Basically, the selection rects were handed to the DxEngine relative to the viewport (which means that some had a negative y-value). At some point, those rects were stored into `size_t`s, resulting in an underflow issue. This caused the renderer to behave strangely when rendering the selection. Generally, these kinds of issues weren't really noticed because selection would always modify a portion of the viewport.

Funny enough, in a way, this satisfies the "mark mode" scenario because the user now has a way to initiate a selection using only the keyboard. Though this isn't ideal, just a fun thing to point out (that's why I'm not closing the mark mode issue).

## Validation Steps Performed
- Verified using DxEngine and AtlasEngine
- select all --> keyboard selection --> start moving the top-left endpoint (and scroll to there)
- select all --> do not scroll automatically
@carlos-zamora carlos-zamora mentioned this issue Jun 28, 2022
Merged
@ghost ghost added the In-PR This issue has a related PR label Jun 28, 2022
@ghost ghost closed this as completed in #13370 Jul 1, 2022
@ghost ghost removed the In-PR This issue has a related PR label Jul 1, 2022
ghost pushed a commit that referenced this issue Jul 1, 2022
@carlos-zamora
Introduce switchSelectionEndpoint action (#13370)
7b8a53c 
## Summary of the Pull Request
Introduces the `switchSelectionEndpoint` action which switches whichever selection endpoint is targeted when a selection is present. For example, if you are targeting "start", `switchSelectionEndpoint` makes it so that now you are targeting "end". This also updates the selection markers appropriately.

## References
Spec - #5804 
#13358
Closes #3663

## Detailed Description of the Pull Request / Additional comments
Most of the code is just standard code of adding a new action. Other than that, we have...
- if there is no selection, the action fails and the keybinding is passed through (similar to `copy()`)
- when we update the selection endpoint, we need to also update the "pivot". This ensures that future calls of `UpdateSelection()` respect this swap.
- [Corner Case] if the cursor is being moved, we make it so that you basically "anchored" an endpoint and you don't have to hold shift anymore.
@ghost ghost added the Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. label Jul 1, 2022
@ghost
Copy link

ghost commented Jul 6, 2022

🎉This issue was addressed in #13370, which has now been successfully released as Windows Terminal Preview v1.15.186.:tada:

Handy links:

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Milestone
22H1
Development

Successfully merging a pull request may close this issue.

Introduce switchSelectionEndpoint action microsoft/terminal
3 participants
@carlos-zamora @DHowett-MSFT @zadjii-msft