-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Introduce Mark Mode #13053
Introduce Mark Mode #13053
Conversation
// TODO CARLOS: should we make this ctrl+shift+m instead? | ||
if (modifiers.IsCtrlPressed() && vkey == 'M') |
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.
Whatcha think?
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
markMode
action - if selection active (from mouse) --> ignore
markMode
action - if no selection (and not in mark mode) --> create selection at cursor
That should permit the shift+left behavior from CMD. Thoughts?
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.
NAK on magic ctrl+m
// TODO CARLOS: should we make this ctrl+shift+m instead? | ||
if (modifiers.IsCtrlPressed() && vkey == 'M') |
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.
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.
@@ -1123,7 +1123,7 @@ namespace winrt::Microsoft::Terminal::Control::implementation | |||
{ | |||
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@@ -1123,7 +1123,7 @@ namespace winrt::Microsoft::Terminal::Control::implementation | |||
{ | |||
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right I forgot about the overlays. Good point.
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.
blocking for time to look today
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm surprised we don't have a helper for this!
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.
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.cpp
just adds logic to prevent the cursor from blinking when in mark modeControlCore
TerminalCore
UpdateSelection()
and other quick edit functions to make mark mode happenValidation Steps Performed