-
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
Fixed #3799: Introduce sendInput command #7249
Conversation
This probably doesn't work because it's unusual to receive the sequence for clearing the screen on the input handle 😄 |
This was my suspicion as well. I've removed the comment from the PR description. Thanks @DHowett! |
@@ -1769,7 +1781,7 @@ namespace winrt::Microsoft::Terminal::TerminalControl::implementation | |||
// - wstr: the string of characters to write to the terminal connection. | |||
// Return Value: | |||
// - <none> | |||
void TermControl::_SendInputToConnection(const std::wstring& wstr) | |||
void TermControl::_SendInputToConnection(const winrt::param::hstring& wstr) |
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.
unfortunately winrt::param
namespace even though it is literally the best namespace for taking in anything that can convert to hstring
We might have to prefer std::wstring_view
, which can be natively converted to an hstring (though it could also crash because hstring expects string_views to be null-terminated)
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've discussed this with the cppwinrt folks before. param::hstring does everything we might possibly want with regards to automatic promotion to hstring, but it's not part of the public interface :/)
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 not entirely sure I understand... Am I supposed to not use winrt::param
because it's a private interface, or is there another technical reason?
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, just because it is a private namespace.
@@ -142,6 +142,7 @@ For commands with arguments: | |||
| `scrollUp` | Move the screen up. | | | | | |||
| `scrollUpPage` | Move the screen up a whole page. | | | | | |||
| `scrollDownPage` | Move the screen down a whole page. | | | | | |||
| `sendInput` | Sends some text input to the shell. | `input` | string | The text input to feed into the shell.<br>ANSI escape sequences may be used. Escape codes like `\x1b` must be written as `\u001b`.<br>For instance the input `"text\n"` will write "text" followed by a newline. `"\u001b[D"` will behave as if the left arrow button had been pressed. | |
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.
Does this classify as "Documentation updated"? Do I need to submit a PR to the docs repo?
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.
Unfortunately, you do!
Ah, that might be inconvenient. It looks like we use std::bind to capture _SendInputToConnection... somewhere |
TermControl.cpp:107 auto inputFn = std::bind(&TermControl::_SendInputToConnection, this, std::placeholders::_1);
_terminal->SetWriteInputCallback(inputFn);
|
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 feel like the resources thing is nitpicking, but hey, there are build breaks too so I don't feel so bad making you change them 😛
Otherwise everything else here looks good 👍
@@ -284,6 +288,7 @@ namespace winrt::TerminalApp::implementation | |||
{ ShortcutAction::ToggleFocusMode, RS_(L"ToggleFocusModeCommandKey") }, | |||
{ ShortcutAction::ToggleFullscreen, RS_(L"ToggleFullscreenCommandKey") }, | |||
{ ShortcutAction::ToggleAlwaysOnTop, RS_(L"ToggleAlwaysOnTopCommandKey") }, | |||
{ ShortcutAction::SendInput, RS_(L"SendInputCommandKey") }, |
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.
IMO this should be mapped to L""
, so that we don't accidentally generate a name for a sendInput
action that doesn't have a value for input
see for example: CloseOtherTabs
// * "Send Input: ...input..." | ||
|
||
return winrt::hstring{ | ||
fmt::format(L"{}: {}", RS_(L"SendInputCommandKey"), _Input) |
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.
Typically, it's best practice to have just two entirely different resources in Resources.resw for something like this.
In this case though, I don't think we need the version without the argument at all, we could probably get away with a single resource for the formatted version:
<data name="SendInputCommandKey" xml:space="preserve">
<value>Send Input: "{0}"</value>
<comment>{0} will be replaced with a string of input as defined by the user.</comment>
</data>
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 suddenly worried about dropping the user's input right into a TextBlock. Should we transform the control characters <0x20 to their "control pictures" equivalents? It's as easy as adding 0x2400 to them!
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.
This is what we do in the debug tap ... which I can't get a screenshot of because we broke it o_O
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.
Or perhaps my right alt key no longer works. This would come as no big surprise.
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.
Should we transform the control characters <0x20 to their "control pictures" equivalents? It's as easy as adding 0x2400 to them!
I'm hugely in favor of this actually. Raw control characters might definitely will break the text block
"Otherwise everything else here looks good 👍"
Hello @zadjii-msft! 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 (
|
Thanks for doing this @lhecker! Thanks as well and as always to @zadjii-msft & @DHowett, of course! |
🎉 Handy links: |
How would I actually use this functionality to send input from an external program into an active terminal ? |
@musm This "command" is currently / at this point only for use with key bindings inside the Windows Terminal (WT) app. |
Hi, Windows Terminal sends
it now just eats the key and does nothing. This shows that the configuration had an effect, but it seems like it's not working properly for escape codes as the documentation suggests. Any ideas? |
I did some tests, and I found that it seems like the key will send if the For example, |
We do not have an allowlist. The literal string in the sendInput action is sent through unfiltered. If the receiving application rejects it, that’s not our fault. |
How can I prove that it's just eating the key? That's just what it's doing. I'm currently running
I'm searching for an equivalent of So far the procedure has been
|
I'm pretty sure then (similar to how i eventually found out that openssh is responsible for making mouse codes fail) that |
Great, I've got MSYS2 installed, and with the OpenSSH obtained through there it behaves as you described. Mouse events still not working but that's ok for now. |
Oh yeah, so SSH 7.7 shipped with Windows actually tells us that it cannot handle VT input and needs us to translate it into Windows events ... so that it can translate them back into VT. this has since been fixed, but the damage is done for two fairly popular windows versions (1904x and 1836x) |
Summary of the Pull Request
This PR enables users to send arbitrary text input to the shell via a keybinding.
PR Checklist
Detailed Description of the Pull Request / Additional comments
Validation Steps Performed
Added the following keybindings:
Ensured that when pressing P "foobar" is echoed to the shell and when pressing Q the shell history is being navigated backwards.