Conversation
| // TODO CARLOS: should we make this ctrl+shift+m instead? | ||
| if (modifiers.IsCtrlPressed() && vkey == 'M') |
There was a problem hiding this comment.
make this an action, default it to ctrl+shift+m. The keybindings w/in mark mode don't need to be configurable now, but the toggle should be.
There was a problem hiding this comment.
That seems reasonable to me. Then your shift+left behavior from CMD will exist if you want it to.
There was a problem hiding this comment.
Actually, you still won't be able to get that shift+left behavior. Binding markMode to that will make it so that you can't use shift+left to select towards the left. Right now, I have the markMode action work as a toggle...
- if in mark mode --> exit mark mode
- if not in mark mode (even if there's a mouse selection present) --> enter mark mode --> create selection at cursor
That said, I'm not too sure about this behavior. Definitely shippable, but open to changing it.
We could do this (but I'm concerned it may be overcomplicating it)...
- if in mark mode --> ignore
markModeaction - if selection active (from mouse) --> ignore
markModeaction - if no selection (and not in mark mode) --> create selection at cursor
That should permit the shift+left behavior from CMD. Thoughts?
| // TODO CARLOS: should we make this ctrl+shift+m instead? | ||
| if (modifiers.IsCtrlPressed() && vkey == 'M') |
There was a problem hiding this comment.
make this an action, default it to ctrl+shift+m. The keybindings w/in mark mode don't need to be configurable now, but the toggle should be.
| // Manually show the cursor when a key is pressed. Restarting | ||
| // the timer prevents flickering. | ||
| _core.CursorOn(true); | ||
| _core.CursorOn(!_core.IsInMarkMode()); |
There was a problem hiding this comment.
is this right? On is literally the on/off blink state of the cursor (e.g. when it's drawn, it's on, then it blinks to off and is not drawn, then blinks back to on)
So we don't want the cursor to be shown at all when in mark mode?
There was a problem hiding this comment.
Yeah, that's intentional (but definitely up for discussion on the design, actually). I'll just rapid fire random thoughts in my head for why I feel this is the desired behavior...
- the cursor is a bit distracting when it's blinking if you're in mark mode
- preventing the cursor from blinking makes it feel more clear that you're in a different mode (though we're looking to add the markers in Add selection marker overlays for keyboard selection #10865 )
- when in mark mode, the "cursor" should really be the selection marker (just like in a text editor). So there's no reason to show the actual cursor.
- [Accessibility] we do need to track the cursor movements for some things. Maybe we should actually be moving the cursor along with the selection? Idk. I'll have to test this out.
There was a problem hiding this comment.
Ah right I forgot about the overlays. Good point.
|
Team discuss:
|
src/cascadia/TerminalSettingsModel/Resources/en-US/Resources.resw
Outdated
Show resolved
Hide resolved
099a8e2 to
2d71c2c
Compare
src/cascadia/TerminalSettingsModel/Resources/en-US/Resources.resw
Outdated
Show resolved
Hide resolved
| // Manually show the cursor when a key is pressed. Restarting | ||
| // the timer prevents flickering. | ||
| _core.CursorOn(true); | ||
| _core.CursorOn(!_core.IsInMarkMode()); |
There was a problem hiding this comment.
Ah right I forgot about the overlays. Good point.
DHowett
left a comment
There was a problem hiding this comment.
blocking for time to look today
DHowett
left a comment
There was a problem hiding this comment.
okay, so some selections are selections and some selections are mark mode selections? I can get behind that. My only concern is that selection one, because it impacts specifically me and it is not configurable. I don't think it SHOULD be configurable, i just think that a PR adding mark mode should not sneak in any changes to the non-mark mode ;)
| auto lock = _terminal->LockForWriting(); | ||
| _terminal->SelectAll(); | ||
| _renderer->TriggerSelection(); |
There was a problem hiding this comment.
I'm surprised we don't have a helper for this!
There was a problem hiding this comment.
yeah, I think at one point I made (or witnessed) the decision that triggering the renderer and (un)locking would be handled at the control core layer consistently to ensure we don't deadlock on accident. It's a little annoying, but we could swing the pendulum the other way hahaha
|
Hello @DHowett! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
|
When will this be released? Also since there's not much documentation, can you please tell me if this will satisfy the use case I described here? #6528 |
|
or is this the final feature? #11868 |
|
@ofek We're planning on shipping this in Preview 1.15, the next Terminal release. Typically, these releases are about 6 weeks apart. We'll get to elaborating on the docs once we get closer to release. Trying to parse everything there and translate it to what we've got so far:
|
|
Hey! So I spent this weekend learning & configuring the terminal. It's amazing, and I think I can immediately switch over when this is released. I wanted to test to be sure though so I downloaded the The |
Yep. We don't really have any sort of official nightly channel set up. |
## Summary of the Pull Request
1. [copy on select] when manually copying text (i.e. kbd or right-click) while in mark/quick-edit mode, we now dismiss the selection.
2. `Enter` is now bound to copy by default.
- This works very well with mark mode and provides a more consistent behavior with conhost's selection experience overall.
- "why not hardcode `Enter` as a way to copy when in mark mode?"
- In an effort to make this as configurable as possible, I decided to make it a configurable keybinding, but am open to suggestions.
3. selection markers
a. we now hide the selection markers when multi-clicking the terminal.
b. selection markers are now properly shown when a single cell selection exists
- Prior to this PR, any single cell selection would display both markers. Now, we actually track which endpoint we're moving and display the appropriate one.
4. ensures that when you use keyboard selection to move past the top/bottom of the scroll area, we clamp it to the origin/bottom-right respectively. The fix is also better here in that it provides consistent behavior across all of the `_MoveByX` functions.
5. adds `toggleBlockSelection` to the schema
## References
#13053
## Validation Steps Performed
Did a whole flowchart of expected behavior with copy on select:
- enable `copyOnSelect`
- make a selection with the mouse
- ✅ right-click should copy the text --> clear the selection --> paste
- use keyboard selection to quick-edit the existing selection
- ✅ `copy` action should clear the selection
- ✅ right-click should copy the text --> clear the selection --> paste
Played with selection markers a bit in mark mode and quick edit mode. Markers are updating appropriately.
|
🎉 Handy links: |
|
I'm now able to use Windows Terminal without fatigue from heavy mouse movement. Thank you very much!!! |
Summary of the Pull Request
Introduces a non-configurable version of mark mode to Windows Terminal. It has the following interactions defined:
When in mark mode, the cursor does not blink.
References
#4993 - [Epic] Keyboard Selection
PR Checklist
Detailed Description of the Pull Request / Additional comments
TermControl:TermControl.cppjust adds logic to prevent the cursor from blinking when in mark modeControlCoreTerminalCoreUpdateSelection()and other quick edit functions to make mark mode happenValidation Steps Performed