-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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
Add an experimental setting for moving the cursor with the mouse #15758
Conversation
_terminal->SendKeyEvent(key, 0, {}, true); | ||
_terminal->SendKeyEvent(key, 0, {}, false); |
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.
For purposes like this it would be nice if we could stop flushing our input pipe so that the keystrokes are sent as a unison. For both pwsh and cmd this would avoid re-printing the entire commandline on every cursor navigation. One option would be to do something like _terminal->CorkInputPipe()
and UncorkInputPipe()
(borrowing TCP_CORK
terminology), but I also somewhat feel like it would be better if we instead made it so that SendKeyEvent
will never flush the input pipe and instead we add a _terminal->FlushInput()
function which you need to call when you're done generating input. Alternatively, we could also extract TerminalInput
out of Terminal
s control and accumulate a std::string
here before sending it off. Or we just generate cursor sequences ourselves. I don't think there's any fantastic solution, but there's a lot of alright ones. 🙂
(xterm.js does this as well btw.)
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.
Could we create a follow-up issue for this? I think it would be worthwhile in general to keep track of features that would benefit of corking/uncorking the input pipe.
TODO!
gotta find a way to clamp it to the rightmost character. Probably wont work right for folks with right-aligned prompts. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
nit: maybe |
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.
Sorry to block two in a row, but I've got Questions! And a suggestion for a name.
false, | ||
needToCopy); | ||
|
||
VERIFY_IS_TRUE(core->HasSelection()); |
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.
wait, why now does a single left click result in a selection? I thought it for sure didn't do that...
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 true
means shift was pressed. A single click with a shift does select
VERIFY_ARE_EQUAL(expectedStart, start); | ||
VERIFY_ARE_EQUAL(expectedEnd, end); | ||
} | ||
VERIFY_IS_TRUE(gotSelectionUpdate); |
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 don't actually understand how this selection test is related to click-to-reposition...
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.
It's actually not! But I broke that selection rendering thing in that last bug bash, in an earlier commit in this PR. This test I wrote to make sure I un-broke it, and won't re-break it in the future.
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.
Oh, I see. I thought it was a render lock bug, so i didn't put the two together
Sure, I don't care |
This comment has been minimized.
This comment has been minimized.
(force merging since it seems like GH is confused. Probably since we changed the build rules during the course of this PR) |
I could list the PRs but I aint got time for that closes #687 closes #668 Docs microsoft/terminal#15758
Summary of the Pull Request
This adds a new experimental per-setting to the terminal.
When:
133;B
)we'll send a number of simulated keystrokes to the terminal based off the number of cells between the place clicked and where the current mouse cursor is.
PR Checklist
Detailed Description of the Pull Request / Additional comments
There was a LOT of discussion in #8573. This is kinda a best effort feature - it won't always work, but it should improve the experience most of the time. We all kinda agreed that as much as the shell probably should be responsible for doing this, there's myriad reasons that won't work in practicality:
And eventually settled that this was the least horrifying comprimise.
This has e d g e c a s e s:
vim
/emacs
? Nope.ESC
(which are rendered by the shell as two cells "^[")? Nope.https://github.com/xtermjs/xterm.js/blob/master/src/browser/input/MoveToCell.ts has probably a more complete implementation of how we'd want to generate the keypresses and such.