2020-01-27 16:34:12 +01:00
|
|
|
// Copyright (c) Microsoft Corporation.
|
|
|
|
// Licensed under the MIT license.
|
|
|
|
|
|
|
|
#include "pch.h"
|
|
|
|
#include <WexTestClass.h>
|
|
|
|
|
2020-11-20 05:36:18 +01:00
|
|
|
#include "../types/inc/utils.hpp"
|
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
|
|
|
#include "../TerminalApp/TerminalPage.h"
|
2021-02-22 19:50:39 +01:00
|
|
|
#include "../TerminalApp/AppLogic.h"
|
2020-01-27 16:34:12 +01:00
|
|
|
#include "../TerminalApp/AppCommandlineArgs.h"
|
2021-02-22 19:50:39 +01:00
|
|
|
#include "../inc/WindowingBehavior.h"
|
2020-01-27 16:34:12 +01:00
|
|
|
|
|
|
|
using namespace WEX::Logging;
|
|
|
|
using namespace WEX::Common;
|
|
|
|
using namespace WEX::TestExecution;
|
|
|
|
|
2021-02-22 19:50:39 +01:00
|
|
|
using namespace winrt;
|
2020-10-06 18:56:59 +02:00
|
|
|
using namespace winrt::Microsoft::Terminal::Settings::Model;
|
2020-01-27 16:34:12 +01:00
|
|
|
using namespace winrt::TerminalApp;
|
|
|
|
using namespace ::TerminalApp;
|
|
|
|
|
2021-02-22 19:50:39 +01:00
|
|
|
namespace winrt
|
|
|
|
{
|
|
|
|
namespace appImpl = TerminalApp::implementation;
|
|
|
|
}
|
|
|
|
|
2020-01-27 16:34:12 +01:00
|
|
|
namespace TerminalAppLocalTests
|
|
|
|
{
|
|
|
|
// TODO:microsoft/terminal#3838:
|
|
|
|
// Unfortunately, these tests _WILL NOT_ work in our CI. We're waiting for
|
|
|
|
// an updated TAEF that will let us install framework packages when the test
|
|
|
|
// package is deployed. Until then, these tests won't deploy in CI.
|
|
|
|
class CommandlineTest
|
|
|
|
{
|
|
|
|
// Use a custom AppxManifest to ensure that we can activate winrt types
|
|
|
|
// from our test. This property will tell taef to manually use this as
|
|
|
|
// the AppxManifest for this test class.
|
|
|
|
// This does not yet work for anything XAML-y. See TabTests.cpp for more
|
|
|
|
// details on that.
|
|
|
|
BEGIN_TEST_CLASS(CommandlineTest)
|
|
|
|
TEST_CLASS_PROPERTY(L"RunAs", L"UAP")
|
|
|
|
TEST_CLASS_PROPERTY(L"UAP:AppXManifest", L"TestHostAppXManifest.xml")
|
|
|
|
END_TEST_CLASS()
|
|
|
|
|
|
|
|
TEST_METHOD(ParseSimpleCommandline);
|
|
|
|
TEST_METHOD(ParseTrickyCommandlines);
|
|
|
|
TEST_METHOD(TestEscapeDelimiters);
|
|
|
|
|
|
|
|
TEST_METHOD(ParseSimpleHelp);
|
|
|
|
TEST_METHOD(ParseBadOptions);
|
|
|
|
TEST_METHOD(ParseSubcommandHelp);
|
|
|
|
|
|
|
|
TEST_METHOD(ParseBasicCommandlineIntoArgs);
|
|
|
|
TEST_METHOD(ParseNewTabCommand);
|
|
|
|
TEST_METHOD(ParseSplitPaneIntoArgs);
|
|
|
|
TEST_METHOD(ParseComboCommandlineIntoArgs);
|
|
|
|
TEST_METHOD(ParseFocusTabArgs);
|
Add a `move-focus` subcommand (#8546)
## Summary of the Pull Request
Adds support for the `move-focus` subcommand to `wt.exe`. This subcommand works _exactly_ like `moveFocus(up|down|left|right)`.
## References
* Will surely conflict with #8183
* Is goodness even in the world where #5464 exists
## PR Checklist
* [x] Closes #6580
* [x] I work here
* [x] Tests added/passed
* [x] Docs PR: MicrosoftDocs/terminal#209
## Detailed Description of the Pull Request / Additional comments
Bear with me, I wrote this before paternity leave, so code might be a bit stale.
Oddly, after startup, this _does not_ leave the focus on the pane you moved to. If you `move-focus` during startup, at the end of startup, we'll still focus a _random_ pane. This is because the terminal still auto-focus a TermControl when it's done with layout. While we'll maintain the active control just fine during the startup, at the end of startup, all the controls will complete layout in a random order.
This is no different than the startup right now. `wt sp ; sp ; sp` will focus a random pane at the end. This is left for a future someone to fix
This is also subject to #2398 / #4692. Moving in a direction isn't _totally_ reliable currently. `focus-pane -t ID` will certainly be more reliable, but this will work in the meantime?
## Validation Steps Performed
Opened probably 100 terminals, confirmed that the layout was always correct. Final focused pane was random, but the layout was right.
2021-01-11 19:37:05 +01:00
|
|
|
TEST_METHOD(ParseMoveFocusArgs);
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
TEST_METHOD(ParseSwapPaneArgs);
|
2020-01-29 22:01:05 +01:00
|
|
|
TEST_METHOD(ParseArgumentsWithParsingTerminators);
|
2021-05-21 23:55:57 +02:00
|
|
|
TEST_METHOD(ParseFocusPaneArgs);
|
2020-01-27 16:34:12 +01:00
|
|
|
|
|
|
|
TEST_METHOD(ParseNoCommandIsNewTab);
|
|
|
|
|
|
|
|
TEST_METHOD(ValidateFirstCommandIsNewTab);
|
|
|
|
|
|
|
|
TEST_METHOD(CheckTypos);
|
|
|
|
|
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
|
|
|
TEST_METHOD(TestSimpleExecuteCommandlineAction);
|
|
|
|
TEST_METHOD(TestMultipleCommandExecuteCommandlineAction);
|
|
|
|
TEST_METHOD(TestInvalidExecuteCommandlineAction);
|
2020-10-15 00:19:51 +02:00
|
|
|
TEST_METHOD(TestLaunchMode);
|
2020-11-18 22:04:35 +01:00
|
|
|
TEST_METHOD(TestLaunchModeWithNoCommand);
|
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
|
|
|
|
2021-01-13 00:19:55 +01:00
|
|
|
TEST_METHOD(TestMultipleSplitPaneSizes);
|
|
|
|
|
2021-02-22 19:50:39 +01:00
|
|
|
TEST_METHOD(TestFindTargetWindow);
|
|
|
|
TEST_METHOD(TestFindTargetWindowHelp);
|
|
|
|
TEST_METHOD(TestFindTargetWindowVersion);
|
|
|
|
|
2020-01-27 16:34:12 +01:00
|
|
|
private:
|
|
|
|
void _buildCommandlinesHelper(AppCommandlineArgs& appArgs,
|
|
|
|
const size_t expectedSubcommands,
|
|
|
|
std::vector<const wchar_t*>& rawCommands)
|
|
|
|
{
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(expectedSubcommands, commandlines.size());
|
|
|
|
for (auto& cmdBlob : commandlines)
|
|
|
|
{
|
|
|
|
const auto result = appArgs.ParseCommand(cmdBlob);
|
|
|
|
VERIFY_ARE_EQUAL(0, result);
|
|
|
|
}
|
|
|
|
appArgs.ValidateStartupCommands();
|
|
|
|
}
|
|
|
|
|
Add a `move-focus` subcommand (#8546)
## Summary of the Pull Request
Adds support for the `move-focus` subcommand to `wt.exe`. This subcommand works _exactly_ like `moveFocus(up|down|left|right)`.
## References
* Will surely conflict with #8183
* Is goodness even in the world where #5464 exists
## PR Checklist
* [x] Closes #6580
* [x] I work here
* [x] Tests added/passed
* [x] Docs PR: MicrosoftDocs/terminal#209
## Detailed Description of the Pull Request / Additional comments
Bear with me, I wrote this before paternity leave, so code might be a bit stale.
Oddly, after startup, this _does not_ leave the focus on the pane you moved to. If you `move-focus` during startup, at the end of startup, we'll still focus a _random_ pane. This is because the terminal still auto-focus a TermControl when it's done with layout. While we'll maintain the active control just fine during the startup, at the end of startup, all the controls will complete layout in a random order.
This is no different than the startup right now. `wt sp ; sp ; sp` will focus a random pane at the end. This is left for a future someone to fix
This is also subject to #2398 / #4692. Moving in a direction isn't _totally_ reliable currently. `focus-pane -t ID` will certainly be more reliable, but this will work in the meantime?
## Validation Steps Performed
Opened probably 100 terminals, confirmed that the layout was always correct. Final focused pane was random, but the layout was right.
2021-01-11 19:37:05 +01:00
|
|
|
void _buildCommandlinesExpectFailureHelper(AppCommandlineArgs& appArgs,
|
|
|
|
const size_t expectedSubcommands,
|
|
|
|
std::vector<const wchar_t*>& rawCommands)
|
|
|
|
{
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(expectedSubcommands, commandlines.size());
|
|
|
|
for (auto& cmdBlob : commandlines)
|
|
|
|
{
|
|
|
|
const auto result = appArgs.ParseCommand(cmdBlob);
|
|
|
|
VERIFY_ARE_NOT_EQUAL(0, result);
|
|
|
|
VERIFY_ARE_NOT_EQUAL("", appArgs._exitMessage);
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"Exit Message:\n%hs",
|
|
|
|
appArgs._exitMessage.c_str()));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-27 16:34:12 +01:00
|
|
|
void _logCommandline(std::vector<const wchar_t*>& rawCommands)
|
|
|
|
{
|
|
|
|
std::wstring buffer;
|
|
|
|
for (const auto s : rawCommands)
|
|
|
|
{
|
|
|
|
buffer += s;
|
|
|
|
buffer += L" ";
|
|
|
|
}
|
|
|
|
Log::Comment(NoThrowString().Format(L"%s", buffer.c_str()));
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
void CommandlineTest::ParseSimpleCommandline()
|
|
|
|
{
|
|
|
|
{
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe" };
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(0).Argc());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"an arg with spaces" };
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(2u, commandlines.at(0).Argc());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"--parameter", L"an arg with spaces" };
|
|
|
|
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(3u, commandlines.at(0).Argc());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"new-tab" };
|
|
|
|
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(2u, commandlines.at(0).Argc());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"new-tab", L";" };
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(2u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(2u, commandlines.at(0).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(0).Args().at(0));
|
|
|
|
VERIFY_ARE_EQUAL("new-tab", commandlines.at(0).Args().at(1));
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(1).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(1).Args().at(0));
|
|
|
|
}
|
|
|
|
{
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L";" };
|
|
|
|
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(2u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(0).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(0).Args().at(0));
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(1).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(1).Args().at(0));
|
|
|
|
}
|
|
|
|
{
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L";", L";" };
|
|
|
|
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(3u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(0).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(0).Args().at(0));
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(1).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(1).Args().at(0));
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(2).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(2).Args().at(0));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::ParseSimpleHelp()
|
|
|
|
{
|
|
|
|
static std::vector<std::vector<const wchar_t*>> commandsToTest{
|
|
|
|
{ L"wt.exe", L"/?" },
|
|
|
|
{ L"wt.exe", L"-?" },
|
|
|
|
{ L"wt.exe", L"-h" },
|
|
|
|
{ L"wt.exe", L"--help" }
|
|
|
|
};
|
|
|
|
BEGIN_TEST_METHOD_PROPERTIES()
|
|
|
|
TEST_METHOD_PROPERTY(L"Data:testPass", L"{0, 1, 2, 3}")
|
|
|
|
END_TEST_METHOD_PROPERTIES();
|
|
|
|
int testPass;
|
|
|
|
VERIFY_SUCCEEDED(TestData::TryGetValue(L"testPass", testPass), L"Get a commandline to test");
|
|
|
|
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*>& rawCommands{ commandsToTest.at(testPass) };
|
|
|
|
_logCommandline(rawCommands);
|
|
|
|
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(2u, commandlines.at(0).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(0).Args().at(0));
|
|
|
|
|
|
|
|
for (auto& cmdBlob : commandlines)
|
|
|
|
{
|
|
|
|
const auto result = appArgs.ParseCommand(cmdBlob);
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"Exit Message:\n%hs",
|
|
|
|
appArgs._exitMessage.c_str()));
|
|
|
|
VERIFY_ARE_EQUAL(0, result);
|
|
|
|
VERIFY_ARE_NOT_EQUAL("", appArgs._exitMessage);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::ParseBadOptions()
|
|
|
|
{
|
|
|
|
static std::vector<std::vector<const wchar_t*>> commandsToTest{
|
|
|
|
{ L"wt.exe", L"/Z" },
|
|
|
|
{ L"wt.exe", L"-q" },
|
|
|
|
{ L"wt.exe", L"--bar" }
|
|
|
|
};
|
|
|
|
BEGIN_TEST_METHOD_PROPERTIES()
|
|
|
|
TEST_METHOD_PROPERTY(L"Data:testPass", L"{0, 1, 2}")
|
|
|
|
END_TEST_METHOD_PROPERTIES();
|
|
|
|
int testPass;
|
|
|
|
VERIFY_SUCCEEDED(TestData::TryGetValue(L"testPass", testPass), L"Get a commandline to test");
|
|
|
|
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*>& rawCommands{ commandsToTest.at(testPass) };
|
|
|
|
_logCommandline(rawCommands);
|
|
|
|
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(2u, commandlines.at(0).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(0).Args().at(0));
|
|
|
|
|
|
|
|
for (auto& cmdBlob : commandlines)
|
|
|
|
{
|
|
|
|
const auto result = appArgs.ParseCommand(cmdBlob);
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"Exit Message:\n%hs",
|
|
|
|
appArgs._exitMessage.c_str()));
|
|
|
|
VERIFY_ARE_NOT_EQUAL(0, result);
|
|
|
|
VERIFY_ARE_NOT_EQUAL("", appArgs._exitMessage);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::ParseSubcommandHelp()
|
|
|
|
{
|
|
|
|
static std::vector<std::vector<const wchar_t*>> commandsToTest{
|
|
|
|
{ L"wt.exe", L"new-tab", L"-h" },
|
|
|
|
{ L"wt.exe", L"new-tab", L"--help" },
|
|
|
|
{ L"wt.exe", L"split-pane", L"-h" },
|
|
|
|
{ L"wt.exe", L"split-pane", L"--help" }
|
|
|
|
};
|
|
|
|
BEGIN_TEST_METHOD_PROPERTIES()
|
|
|
|
TEST_METHOD_PROPERTY(L"Data:testPass", L"{0, 1, 2, 3}")
|
|
|
|
END_TEST_METHOD_PROPERTIES();
|
|
|
|
int testPass;
|
|
|
|
VERIFY_SUCCEEDED(TestData::TryGetValue(L"testPass", testPass), L"Get a commandline to test");
|
|
|
|
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*>& rawCommands{ commandsToTest.at(testPass) };
|
|
|
|
_logCommandline(rawCommands);
|
|
|
|
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(3u, commandlines.at(0).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(0).Args().at(0));
|
|
|
|
|
|
|
|
for (auto& cmdBlob : commandlines)
|
|
|
|
{
|
|
|
|
const auto result = appArgs.ParseCommand(cmdBlob);
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"Exit Message:\n%hs",
|
|
|
|
appArgs._exitMessage.c_str()));
|
|
|
|
VERIFY_ARE_EQUAL(0, result);
|
|
|
|
VERIFY_ARE_NOT_EQUAL("", appArgs._exitMessage);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::ParseTrickyCommandlines()
|
|
|
|
{
|
|
|
|
{
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"new-tab;" };
|
|
|
|
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(2u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(2u, commandlines.at(0).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(0).Args().at(0));
|
|
|
|
VERIFY_ARE_EQUAL("new-tab", commandlines.at(0).Args().at(1));
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(1).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(1).Args().at(0));
|
|
|
|
}
|
|
|
|
{
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L";new-tab;" };
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(3u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(0).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(0).Args().at(0));
|
|
|
|
VERIFY_ARE_EQUAL(2u, commandlines.at(1).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(1).Args().at(0));
|
|
|
|
VERIFY_ARE_EQUAL("new-tab", commandlines.at(1).Args().at(1));
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(2).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(2).Args().at(0));
|
|
|
|
}
|
|
|
|
{
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe;" };
|
|
|
|
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(2u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(0).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(0).Args().at(0));
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(1).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(1).Args().at(0));
|
|
|
|
}
|
|
|
|
{
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe;;" };
|
|
|
|
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(3u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(0).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(0).Args().at(0));
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(1).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(1).Args().at(0));
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(2).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(2).Args().at(0));
|
|
|
|
}
|
|
|
|
{
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe;foo;bar;baz" };
|
|
|
|
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(4u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.at(0).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(0).Args().at(0));
|
|
|
|
VERIFY_ARE_EQUAL(2u, commandlines.at(1).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(1).Args().at(0));
|
|
|
|
VERIFY_ARE_EQUAL("foo", commandlines.at(1).Args().at(1));
|
|
|
|
VERIFY_ARE_EQUAL(2u, commandlines.at(2).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(2).Args().at(0));
|
|
|
|
VERIFY_ARE_EQUAL("bar", commandlines.at(2).Args().at(1));
|
|
|
|
VERIFY_ARE_EQUAL(2u, commandlines.at(3).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(3).Args().at(0));
|
|
|
|
VERIFY_ARE_EQUAL("baz", commandlines.at(3).Args().at(1));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::TestEscapeDelimiters()
|
|
|
|
{
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"new-tab", L"powershell.exe", L"This is an arg ; with spaces" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 2u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
{
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
auto myCommand = myArgs.TerminalArgs().Commandline();
|
|
|
|
VERIFY_ARE_EQUAL(L"powershell.exe \"This is an arg \"", myCommand);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
auto myCommand = myArgs.TerminalArgs().Commandline();
|
|
|
|
VERIFY_ARE_EQUAL(L"\" with spaces\"", myCommand);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"new-tab", L"powershell.exe", L"This is an arg \\; with spaces" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
{
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
auto myCommand = myArgs.TerminalArgs().Commandline();
|
|
|
|
VERIFY_ARE_EQUAL(L"powershell.exe \"This is an arg ; with spaces\"", myCommand);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::ParseBasicCommandlineIntoArgs()
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"new-tab" };
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::ParseNewTabCommand()
|
|
|
|
{
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
BEGIN_TEST_METHOD_PROPERTIES()
|
|
|
|
TEST_METHOD_PROPERTY(L"Data:useShortForm", L"{false, true}")
|
|
|
|
END_TEST_METHOD_PROPERTIES()
|
|
|
|
|
|
|
|
INIT_TEST_PROPERTY(bool, useShortForm, L"If true, use `nt` instead of `new-tab`");
|
|
|
|
const wchar_t* subcommand = useShortForm ? L"nt" : L"new-tab";
|
|
|
|
|
2020-01-27 16:34:12 +01:00
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
2021-03-29 22:04:39 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"--profile", L"cmd" };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"cmd", myArgs.TerminalArgs().Profile());
|
2021-03-29 22:04:39 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"--startingDirectory", L"c:\\Foo" };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"c:\\Foo", myArgs.TerminalArgs().StartingDirectory());
|
2021-03-29 22:04:39 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"powershell.exe" };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"powershell.exe", myArgs.TerminalArgs().Commandline());
|
2021-03-29 22:04:39 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"powershell.exe", L"This is an arg with spaces" };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
auto myCommand = myArgs.TerminalArgs().Commandline();
|
|
|
|
VERIFY_ARE_EQUAL(L"powershell.exe \"This is an arg with spaces\"", myCommand);
|
2021-03-29 22:04:39 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"powershell.exe", L"This is an arg with spaces", L"another-arg", L"more spaces in this one" };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
auto myCommand = myArgs.TerminalArgs().Commandline();
|
|
|
|
VERIFY_ARE_EQUAL(L"powershell.exe \"This is an arg with spaces\" another-arg \"more spaces in this one\"", myCommand);
|
2021-03-29 22:04:39 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-p", L"Windows PowerShell" };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"Windows PowerShell", myArgs.TerminalArgs().Profile());
|
2021-03-29 22:04:39 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"wsl", L"-d", L"Alpine" };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"wsl -d Alpine", myArgs.TerminalArgs().Commandline());
|
2021-03-29 22:04:39 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-p", L"1", L"wsl", L"-d", L"Alpine" };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"wsl -d Alpine", myArgs.TerminalArgs().Commandline());
|
|
|
|
VERIFY_ARE_EQUAL(L"1", myArgs.TerminalArgs().Profile());
|
2021-03-29 22:04:39 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
2020-11-20 05:36:18 +01:00
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"--tabColor", L"#009999" };
|
2021-02-22 19:50:39 +01:00
|
|
|
const auto expectedColor = ::Microsoft::Console::Utils::ColorFromHexString("#009999");
|
2020-11-20 05:36:18 +01:00
|
|
|
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_ARE_EQUAL(til::color(myArgs.TerminalArgs().TabColor().Value()), expectedColor);
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
2021-03-29 22:04:39 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"--colorScheme", L"Vintage" };
|
|
|
|
const winrt::hstring expectedScheme{ L"Vintage" };
|
|
|
|
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().ColorScheme().empty());
|
|
|
|
VERIFY_ARE_EQUAL(expectedScheme, myArgs.TerminalArgs().ColorScheme());
|
2020-11-20 05:36:18 +01:00
|
|
|
}
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::ParseSplitPaneIntoArgs()
|
|
|
|
{
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
BEGIN_TEST_METHOD_PROPERTIES()
|
|
|
|
TEST_METHOD_PROPERTY(L"Data:useShortForm", L"{false, true}")
|
|
|
|
END_TEST_METHOD_PROPERTIES()
|
|
|
|
|
|
|
|
INIT_TEST_PROPERTY(bool, useShortForm, L"If true, use `sp` instead of `split-pane`");
|
|
|
|
const wchar_t* subcommand = useShortForm ? L"sp" : L"split-pane";
|
|
|
|
|
2020-01-27 16:34:12 +01:00
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
// The one we actually want to test here is the SplitPane action we created
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
2021-09-15 22:14:57 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
|
2021-03-30 00:06:05 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitType::Manual, myArgs.SplitMode());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-H" };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
// The one we actually want to test here is the SplitPane action we created
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
2021-09-15 22:14:57 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitDirection::Down, myArgs.SplitDirection());
|
2021-03-30 00:06:05 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitType::Manual, myArgs.SplitMode());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-V" };
|
2020-01-27 16:34:12 +01:00
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.size());
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
// The one we actually want to test here is the SplitPane action we created
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
2021-09-15 22:14:57 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitDirection::Right, myArgs.SplitDirection());
|
2021-03-30 00:06:05 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitType::Manual, myArgs.SplitMode());
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-D" };
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.size());
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
// The one we actually want to test here is the SplitPane action we created
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(SplitType::Duplicate, myArgs.SplitMode());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-p", L"1", L"wsl", L"-d", L"Alpine" };
|
2020-01-27 16:34:12 +01:00
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.size());
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
2021-09-15 22:14:57 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"wsl -d Alpine", myArgs.TerminalArgs().Commandline());
|
|
|
|
VERIFY_ARE_EQUAL(L"1", myArgs.TerminalArgs().Profile());
|
2021-03-29 22:04:39 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-p", L"1", L"-H", L"wsl", L"-d", L"Alpine" };
|
2020-01-27 16:34:12 +01:00
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.size());
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
2021-09-15 22:14:57 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitDirection::Down, myArgs.SplitDirection());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"wsl -d Alpine", myArgs.TerminalArgs().Commandline());
|
|
|
|
VERIFY_ARE_EQUAL(L"1", myArgs.TerminalArgs().Profile());
|
2021-03-29 22:04:39 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-p", L"1", L"wsl", L"-d", L"Alpine", L"-H" };
|
2020-01-27 16:34:12 +01:00
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.size());
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
2021-09-15 22:14:57 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"wsl -d Alpine -H", myArgs.TerminalArgs().Commandline());
|
|
|
|
VERIFY_ARE_EQUAL(L"1", myArgs.TerminalArgs().Profile());
|
2021-03-29 22:04:39 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::ParseComboCommandlineIntoArgs()
|
|
|
|
{
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
BEGIN_TEST_METHOD_PROPERTIES()
|
|
|
|
TEST_METHOD_PROPERTY(L"Data:useShortFormNewTab", L"{false, true}")
|
|
|
|
TEST_METHOD_PROPERTY(L"Data:useShortFormSplitPane", L"{false, true}")
|
|
|
|
END_TEST_METHOD_PROPERTIES()
|
|
|
|
|
|
|
|
INIT_TEST_PROPERTY(bool, useShortFormNewTab, L"If true, use `nt` instead of `new-tab`");
|
|
|
|
INIT_TEST_PROPERTY(bool, useShortFormSplitPane, L"If true, use `sp` instead of `split-pane`");
|
|
|
|
const wchar_t* ntSubcommand = useShortFormNewTab ? L"nt" : L"new-tab";
|
|
|
|
const wchar_t* spSubcommand = useShortFormSplitPane ? L"sp" : L"split-pane";
|
|
|
|
|
2020-01-27 16:34:12 +01:00
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", ntSubcommand, L";", spSubcommand };
|
2020-01-27 16:34:12 +01:00
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
_buildCommandlinesHelper(appArgs, 2u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, appArgs._startupActions.at(1).Action());
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::ParseNoCommandIsNewTab()
|
|
|
|
{
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"--profile", L"cmd" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"cmd", myArgs.TerminalArgs().Profile());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"--startingDirectory", L"c:\\Foo" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"c:\\Foo", myArgs.TerminalArgs().StartingDirectory());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"powershell.exe" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"powershell.exe", myArgs.TerminalArgs().Commandline());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"powershell.exe", L"This is an arg with spaces" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"powershell.exe \"This is an arg with spaces\"", myArgs.TerminalArgs().Commandline());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::ParseFocusTabArgs()
|
|
|
|
{
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
BEGIN_TEST_METHOD_PROPERTIES()
|
|
|
|
TEST_METHOD_PROPERTY(L"Data:useShortForm", L"{false, true}")
|
|
|
|
END_TEST_METHOD_PROPERTIES()
|
|
|
|
|
|
|
|
INIT_TEST_PROPERTY(bool, useShortForm, L"If true, use `ft` instead of `focus-tab`");
|
|
|
|
const wchar_t* subcommand = useShortForm ? L"ft" : L"focus-tab";
|
|
|
|
|
2020-01-27 16:34:12 +01:00
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-n" };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NextTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NULL(actionAndArgs.Args());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-p" };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::PrevTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NULL(actionAndArgs.Args());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-t", L"2" };
|
2020-01-27 16:34:12 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SwitchToTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SwitchToTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
2020-02-04 22:51:11 +01:00
|
|
|
VERIFY_ARE_EQUAL(static_cast<uint32_t>(2), myArgs.TabIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"Attempt an invalid combination of flags"));
|
|
|
|
AppCommandlineArgs appArgs{};
|
`wt.exe`: Add support for "short" sub-commands (#6576)
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes #5466
2020-07-14 20:50:32 +02:00
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-p", L"-n" };
|
2020-01-27 16:34:12 +01:00
|
|
|
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
VERIFY_ARE_EQUAL(1u, commandlines.size());
|
|
|
|
VERIFY_ARE_EQUAL(4u, commandlines.at(0).Argc());
|
|
|
|
VERIFY_ARE_EQUAL("wt.exe", commandlines.at(0).Args().at(0));
|
|
|
|
|
|
|
|
for (auto& cmdBlob : commandlines)
|
|
|
|
{
|
|
|
|
const auto result = appArgs.ParseCommand(cmdBlob);
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"Exit Message:\n%hs",
|
|
|
|
appArgs._exitMessage.c_str()));
|
|
|
|
VERIFY_ARE_NOT_EQUAL(0, result);
|
|
|
|
VERIFY_ARE_NOT_EQUAL("", appArgs._exitMessage);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add a `move-focus` subcommand (#8546)
## Summary of the Pull Request
Adds support for the `move-focus` subcommand to `wt.exe`. This subcommand works _exactly_ like `moveFocus(up|down|left|right)`.
## References
* Will surely conflict with #8183
* Is goodness even in the world where #5464 exists
## PR Checklist
* [x] Closes #6580
* [x] I work here
* [x] Tests added/passed
* [x] Docs PR: MicrosoftDocs/terminal#209
## Detailed Description of the Pull Request / Additional comments
Bear with me, I wrote this before paternity leave, so code might be a bit stale.
Oddly, after startup, this _does not_ leave the focus on the pane you moved to. If you `move-focus` during startup, at the end of startup, we'll still focus a _random_ pane. This is because the terminal still auto-focus a TermControl when it's done with layout. While we'll maintain the active control just fine during the startup, at the end of startup, all the controls will complete layout in a random order.
This is no different than the startup right now. `wt sp ; sp ; sp` will focus a random pane at the end. This is left for a future someone to fix
This is also subject to #2398 / #4692. Moving in a direction isn't _totally_ reliable currently. `focus-pane -t ID` will certainly be more reliable, but this will work in the meantime?
## Validation Steps Performed
Opened probably 100 terminals, confirmed that the layout was always correct. Final focused pane was random, but the layout was right.
2021-01-11 19:37:05 +01:00
|
|
|
void CommandlineTest::ParseMoveFocusArgs()
|
|
|
|
{
|
|
|
|
BEGIN_TEST_METHOD_PROPERTIES()
|
|
|
|
TEST_METHOD_PROPERTY(L"Data:useShortForm", L"{false, true}")
|
|
|
|
END_TEST_METHOD_PROPERTIES()
|
|
|
|
|
|
|
|
INIT_TEST_PROPERTY(bool, useShortForm, L"If true, use `mf` instead of `move-focus`");
|
|
|
|
const wchar_t* subcommand = useShortForm ? L"mf" : L"move-focus";
|
|
|
|
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand };
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"Just the subcommand, without a direction, should fail."));
|
|
|
|
|
|
|
|
_buildCommandlinesExpectFailureHelper(appArgs, 1u, rawCommands);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"left" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::MoveFocus, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<MoveFocusArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(FocusDirection::Left, myArgs.FocusDirection());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"right" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::MoveFocus, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<MoveFocusArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(FocusDirection::Right, myArgs.FocusDirection());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"up" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::MoveFocus, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<MoveFocusArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(FocusDirection::Up, myArgs.FocusDirection());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"down" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::MoveFocus, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<MoveFocusArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(FocusDirection::Down, myArgs.FocusDirection());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"badDirection" };
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"move-focus with an invalid direction should fail."));
|
|
|
|
_buildCommandlinesExpectFailureHelper(appArgs, 1u, rawCommands);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"left", L";", subcommand, L"right" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 2u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(3u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::MoveFocus, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<MoveFocusArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(FocusDirection::Left, myArgs.FocusDirection());
|
|
|
|
|
|
|
|
actionAndArgs = appArgs._startupActions.at(2);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::MoveFocus, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
myArgs = actionAndArgs.Args().try_as<MoveFocusArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(FocusDirection::Right, myArgs.FocusDirection());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
void CommandlineTest::ParseSwapPaneArgs()
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000 #2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 14:53:03 +02:00
|
|
|
{
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
const wchar_t* subcommand = L"swap-pane";
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000 #2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 14:53:03 +02:00
|
|
|
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand };
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"Just the subcommand, without a direction, should fail."));
|
|
|
|
|
|
|
|
_buildCommandlinesExpectFailureHelper(appArgs, 1u, rawCommands);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"left" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SwapPane, actionAndArgs.Action());
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000 #2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 14:53:03 +02:00
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SwapPaneArgs>();
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000 #2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 14:53:03 +02:00
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(FocusDirection::Left, myArgs.Direction());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"right" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SwapPane, actionAndArgs.Action());
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000 #2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 14:53:03 +02:00
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SwapPaneArgs>();
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000 #2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 14:53:03 +02:00
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(FocusDirection::Right, myArgs.Direction());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"up" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SwapPane, actionAndArgs.Action());
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000 #2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 14:53:03 +02:00
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SwapPaneArgs>();
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000 #2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 14:53:03 +02:00
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(FocusDirection::Up, myArgs.Direction());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"down" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SwapPane, actionAndArgs.Action());
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000 #2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 14:53:03 +02:00
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SwapPaneArgs>();
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000 #2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 14:53:03 +02:00
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(FocusDirection::Down, myArgs.Direction());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"badDirection" };
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"move-pane with an invalid direction should fail."));
|
|
|
|
_buildCommandlinesExpectFailureHelper(appArgs, 1u, rawCommands);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"left", L";", subcommand, L"right" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 2u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(3u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SwapPane, actionAndArgs.Action());
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000 #2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 14:53:03 +02:00
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SwapPaneArgs>();
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000 #2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 14:53:03 +02:00
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(FocusDirection::Left, myArgs.Direction());
|
|
|
|
|
|
|
|
actionAndArgs = appArgs._startupActions.at(2);
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SwapPane, actionAndArgs.Action());
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000 #2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 14:53:03 +02:00
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
Move Pane to Tab (GH7075) (#10780)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
myArgs = actionAndArgs.Args().try_as<SwapPaneArgs>();
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000 #2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 14:53:03 +02:00
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(FocusDirection::Right, myArgs.Direction());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-05-21 23:55:57 +02:00
|
|
|
void CommandlineTest::ParseFocusPaneArgs()
|
|
|
|
{
|
|
|
|
BEGIN_TEST_METHOD_PROPERTIES()
|
|
|
|
TEST_METHOD_PROPERTY(L"Data:useShortForm", L"{false, true}")
|
|
|
|
END_TEST_METHOD_PROPERTIES()
|
|
|
|
|
|
|
|
INIT_TEST_PROPERTY(bool, useShortForm, L"If true, use `fp` instead of `focus-pane`");
|
|
|
|
const wchar_t* subcommand = useShortForm ? L"fp" : L"focus-pane";
|
|
|
|
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand };
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"Just the subcommand, without a target, should fail."));
|
|
|
|
|
|
|
|
_buildCommandlinesExpectFailureHelper(appArgs, 1u, rawCommands);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"left" };
|
|
|
|
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"focus-pane without a target should fail."));
|
|
|
|
_buildCommandlinesExpectFailureHelper(appArgs, 1u, rawCommands);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"1" };
|
|
|
|
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"focus-pane without a target should fail."));
|
|
|
|
_buildCommandlinesExpectFailureHelper(appArgs, 1u, rawCommands);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"--target", L"0" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::FocusPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<FocusPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(0u, myArgs.Id());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-t", L"100" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::FocusPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<FocusPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(100u, myArgs.Id());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"--target", L"-1" };
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"focus-pane with an invalid target should fail."));
|
|
|
|
_buildCommandlinesExpectFailureHelper(appArgs, 1u, rawCommands);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"move-focus", L"left", L";", subcommand, L"-t", L"1" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 2u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(3u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
{
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::MoveFocus, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<MoveFocusArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(FocusDirection::Left, myArgs.FocusDirection());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(2);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::FocusPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<FocusPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_ARE_EQUAL(1u, myArgs.Id());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-27 16:34:12 +01:00
|
|
|
void CommandlineTest::ValidateFirstCommandIsNewTab()
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"split-pane", L";", L"split-pane" };
|
|
|
|
auto commandlines = AppCommandlineArgs::BuildCommands(rawCommands);
|
|
|
|
_buildCommandlinesHelper(appArgs, 2u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(3u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, appArgs._startupActions.at(1).Action());
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, appArgs._startupActions.at(2).Action());
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::CheckTypos()
|
|
|
|
{
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"Check what happens when the user typos a subcommand. It should "
|
2020-01-29 22:01:05 +01:00
|
|
|
L"be treated as a commandline"));
|
2020-01-27 16:34:12 +01:00
|
|
|
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"new-tab", L";", L"slpit-pane" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 2u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
|
|
|
|
actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
2020-01-27 16:34:12 +01:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"slpit-pane", myArgs.TerminalArgs().Commandline());
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
Log::Comment(NoThrowString().Format(
|
|
|
|
L"Pass a flag that would be accepted by split-pane, but isn't accepted by new-tab"));
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"slpit-pane", L"-H" };
|
2020-01-29 22:01:05 +01:00
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
2020-01-27 16:34:12 +01:00
|
|
|
|
2020-01-29 22:01:05 +01:00
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
2020-01-27 16:34:12 +01:00
|
|
|
|
2020-01-29 22:01:05 +01:00
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_ARE_EQUAL(L"slpit-pane -H", myArgs.TerminalArgs().Commandline());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::ParseArgumentsWithParsingTerminators()
|
|
|
|
{
|
|
|
|
{ // one parsing terminator, new-tab command
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"new-tab", L"-d", L"C:\\", L"--", L"wsl", L"-d", L"Alpine" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_ARE_EQUAL(L"wsl -d Alpine", myArgs.TerminalArgs().Commandline());
|
|
|
|
VERIFY_ARE_EQUAL(L"C:\\", myArgs.TerminalArgs().StartingDirectory());
|
|
|
|
}
|
|
|
|
{ // two parsing terminators, new-tab command
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"new-tab", L"-d", L"C:\\", L"--", L"wsl", L"-d", L"Alpine", L"--", L"sleep", L"10" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_ARE_EQUAL(L"wsl -d Alpine -- sleep 10", myArgs.TerminalArgs().Commandline());
|
|
|
|
VERIFY_ARE_EQUAL(L"C:\\", myArgs.TerminalArgs().StartingDirectory());
|
|
|
|
}
|
|
|
|
{ // two parsing terminators, *no* command
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"-d", L"C:\\", L"--", L"wsl", L"-d", L"Alpine", L"--", L"sleep", L"10" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_ARE_EQUAL(L"wsl -d Alpine -- sleep 10", myArgs.TerminalArgs().Commandline());
|
|
|
|
VERIFY_ARE_EQUAL(L"C:\\", myArgs.TerminalArgs().StartingDirectory());
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|
|
|
|
}
|
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
|
|
|
|
|
|
|
void CommandlineTest::TestSimpleExecuteCommandlineAction()
|
|
|
|
{
|
2020-10-06 18:56:59 +02:00
|
|
|
ExecuteCommandlineArgs args{ L"new-tab" };
|
2021-02-08 23:01:40 +01:00
|
|
|
auto actions = winrt::TerminalApp::implementation::TerminalPage::ConvertExecuteCommandlineToActions(args);
|
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
|
|
|
VERIFY_ARE_EQUAL(1u, actions.size());
|
|
|
|
auto actionAndArgs = actions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::TestMultipleCommandExecuteCommandlineAction()
|
|
|
|
{
|
2020-10-06 18:56:59 +02:00
|
|
|
ExecuteCommandlineArgs args{ L"new-tab ; split-pane" };
|
2021-02-08 23:01:40 +01:00
|
|
|
auto actions = winrt::TerminalApp::implementation::TerminalPage::ConvertExecuteCommandlineToActions(args);
|
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
|
|
|
VERIFY_ARE_EQUAL(2u, actions.size());
|
|
|
|
{
|
|
|
|
auto actionAndArgs = actions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
auto actionAndArgs = actions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
2020-11-20 05:36:18 +01:00
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
|
|
|
|
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
|
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::TestInvalidExecuteCommandlineAction()
|
|
|
|
{
|
|
|
|
// -H and -V cannot be combined.
|
2020-10-06 18:56:59 +02:00
|
|
|
ExecuteCommandlineArgs args{ L"split-pane -H -V" };
|
2021-02-08 23:01:40 +01:00
|
|
|
auto actions = winrt::TerminalApp::implementation::TerminalPage::ConvertExecuteCommandlineToActions(args);
|
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
|
|
|
VERIFY_ARE_EQUAL(0u, actions.size());
|
|
|
|
}
|
2020-10-15 00:19:51 +02:00
|
|
|
|
|
|
|
void CommandlineTest::TestLaunchMode()
|
|
|
|
{
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_IS_FALSE(appArgs.GetLaunchMode().has_value());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"-F" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(appArgs.GetLaunchMode().has_value());
|
|
|
|
VERIFY_ARE_EQUAL(appArgs.GetLaunchMode().value(), LaunchMode::FullscreenMode);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"--fullscreen" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(appArgs.GetLaunchMode().has_value());
|
|
|
|
VERIFY_ARE_EQUAL(appArgs.GetLaunchMode().value(), LaunchMode::FullscreenMode);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"-M" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(appArgs.GetLaunchMode().has_value());
|
|
|
|
VERIFY_ARE_EQUAL(appArgs.GetLaunchMode().value(), LaunchMode::MaximizedMode);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"--maximized" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(appArgs.GetLaunchMode().has_value());
|
|
|
|
VERIFY_ARE_EQUAL(appArgs.GetLaunchMode().value(), LaunchMode::MaximizedMode);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"-f" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(appArgs.GetLaunchMode().has_value());
|
|
|
|
VERIFY_ARE_EQUAL(appArgs.GetLaunchMode().value(), LaunchMode::FocusMode);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"--focus" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(appArgs.GetLaunchMode().has_value());
|
|
|
|
VERIFY_ARE_EQUAL(appArgs.GetLaunchMode().value(), LaunchMode::FocusMode);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"-fM" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(appArgs.GetLaunchMode().has_value());
|
|
|
|
VERIFY_ARE_EQUAL(appArgs.GetLaunchMode().value(), LaunchMode::MaximizedFocusMode);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"--maximized", L"--focus" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(appArgs.GetLaunchMode().has_value());
|
|
|
|
VERIFY_ARE_EQUAL(appArgs.GetLaunchMode().value(), LaunchMode::MaximizedFocusMode);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"--maximized", L"--focus", L"--focus" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(appArgs.GetLaunchMode().has_value());
|
|
|
|
VERIFY_ARE_EQUAL(appArgs.GetLaunchMode().value(), LaunchMode::MaximizedFocusMode);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"--maximized", L"--focus", L"--maximized" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(appArgs.GetLaunchMode().has_value());
|
|
|
|
VERIFY_ARE_EQUAL(appArgs.GetLaunchMode().value(), LaunchMode::MaximizedFocusMode);
|
|
|
|
}
|
|
|
|
}
|
2020-11-18 22:04:35 +01:00
|
|
|
|
|
|
|
void CommandlineTest::TestLaunchModeWithNoCommand()
|
|
|
|
{
|
|
|
|
{
|
|
|
|
Log::Comment(NoThrowString().Format(L"Pass a launch mode and profile"));
|
|
|
|
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"-M", L"--profile", L"cmd" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(appArgs.GetLaunchMode().has_value());
|
|
|
|
VERIFY_ARE_EQUAL(appArgs.GetLaunchMode().value(), LaunchMode::MaximizedMode);
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ProfileIndex() == nullptr);
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"cmd", myArgs.TerminalArgs().Profile());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
Log::Comment(NoThrowString().Format(L"Pass a launch mode and command line"));
|
|
|
|
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", L"-M", L"powershell.exe" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(appArgs.GetLaunchMode().has_value());
|
|
|
|
VERIFY_ARE_EQUAL(appArgs.GetLaunchMode().value(), LaunchMode::MaximizedMode);
|
|
|
|
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(0);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<NewTabArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
VERIFY_IS_FALSE(myArgs.TerminalArgs().Commandline().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().StartingDirectory().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().TabTitle().empty());
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().ProfileIndex() == nullptr);
|
|
|
|
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
|
|
|
|
VERIFY_ARE_EQUAL(L"powershell.exe", myArgs.TerminalArgs().Commandline());
|
|
|
|
}
|
|
|
|
}
|
2021-01-13 00:19:55 +01:00
|
|
|
|
|
|
|
void CommandlineTest::TestMultipleSplitPaneSizes()
|
|
|
|
{
|
|
|
|
BEGIN_TEST_METHOD_PROPERTIES()
|
|
|
|
TEST_METHOD_PROPERTY(L"Data:useShortForm", L"{false, true}")
|
|
|
|
END_TEST_METHOD_PROPERTIES()
|
|
|
|
|
|
|
|
INIT_TEST_PROPERTY(bool, useShortForm, L"If true, use `sp` instead of `split-pane`");
|
|
|
|
const wchar_t* subcommand = useShortForm ? L"sp" : L"split-pane";
|
|
|
|
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
// The one we actually want to test here is the SplitPane action we created
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
2021-09-15 22:14:57 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
|
2021-01-13 00:19:55 +01:00
|
|
|
VERIFY_ARE_EQUAL(0.5f, myArgs.SplitSize());
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-s", L".3" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(2u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
// The one we actually want to test here is the SplitPane action we created
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
2021-09-15 22:14:57 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
|
2021-01-13 00:19:55 +01:00
|
|
|
VERIFY_ARE_EQUAL(0.3f, myArgs.SplitSize());
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-s", L".3", L";", subcommand };
|
|
|
|
_buildCommandlinesHelper(appArgs, 2u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(3u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
{
|
|
|
|
// The one we actually want to test here is the SplitPane action we created
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
2021-09-15 22:14:57 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
|
2021-01-13 00:19:55 +01:00
|
|
|
VERIFY_ARE_EQUAL(0.3f, myArgs.SplitSize());
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(2);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
2021-09-15 22:14:57 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
|
2021-01-13 00:19:55 +01:00
|
|
|
VERIFY_ARE_EQUAL(0.5f, myArgs.SplitSize());
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AppCommandlineArgs appArgs{};
|
|
|
|
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"-s", L".3", L";", subcommand, L"-s", L".7" };
|
|
|
|
_buildCommandlinesHelper(appArgs, 2u, rawCommands);
|
|
|
|
|
|
|
|
VERIFY_ARE_EQUAL(3u, appArgs._startupActions.size());
|
|
|
|
|
|
|
|
// The first action is going to always be a new-tab action
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, appArgs._startupActions.at(0).Action());
|
|
|
|
|
|
|
|
{
|
|
|
|
// The one we actually want to test here is the SplitPane action we created
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(1);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
2021-09-15 22:14:57 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
|
2021-01-13 00:19:55 +01:00
|
|
|
VERIFY_ARE_EQUAL(0.3f, myArgs.SplitSize());
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
auto actionAndArgs = appArgs._startupActions.at(2);
|
|
|
|
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
|
|
|
|
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
|
|
|
|
auto myArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs);
|
2021-09-15 22:14:57 +02:00
|
|
|
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
|
2021-01-13 00:19:55 +01:00
|
|
|
VERIFY_ARE_EQUAL(0.7f, myArgs.SplitSize());
|
|
|
|
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2021-02-22 19:50:39 +01:00
|
|
|
|
|
|
|
void CommandlineTest::TestFindTargetWindow()
|
|
|
|
{
|
|
|
|
{
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
Log::Comment(L"wt.exe with no args should always use the value from"
|
|
|
|
L" the settings (passed as the second argument).");
|
|
|
|
|
2021-02-22 19:50:39 +01:00
|
|
|
std::vector<winrt::hstring> args{ L"wt.exe" };
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
auto result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseNew);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseExisting, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseAnyExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseAnyExisting, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
}
|
|
|
|
{
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
Log::Comment(L"-w -1 should always result in a new window");
|
|
|
|
|
2021-02-22 19:50:39 +01:00
|
|
|
std::vector<winrt::hstring> args{ L"wt.exe", L"-w", L"-1" };
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
auto result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseNew);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
|
|
|
|
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
|
|
|
|
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseAnyExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
Log::Comment(L"\"new\" should always result in a new window");
|
|
|
|
|
|
|
|
std::vector<winrt::hstring> args{ L"wt.exe", L"-w", L"new" };
|
|
|
|
auto result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseNew);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseAnyExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
}
|
|
|
|
{
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
Log::Comment(L"-w with a negative number should always result in a "
|
|
|
|
L"new window");
|
|
|
|
|
2021-02-22 19:50:39 +01:00
|
|
|
std::vector<winrt::hstring> args{ L"wt.exe", L"-w", L"-12345" };
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
auto result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseNew);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
|
|
|
|
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
|
|
|
|
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseAnyExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
Log::Comment(L"-w with a positive number should result in us trying"
|
|
|
|
L" to either make a new one or find an existing one "
|
|
|
|
L"with that ID, depending on the provided argument");
|
|
|
|
|
|
|
|
std::vector<winrt::hstring> args{ L"wt.exe", L"-w", L"12345" };
|
|
|
|
auto result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseNew);
|
|
|
|
VERIFY_ARE_EQUAL(12345, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseExisting);
|
|
|
|
VERIFY_ARE_EQUAL(12345, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseAnyExisting);
|
|
|
|
VERIFY_ARE_EQUAL(12345, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
}
|
|
|
|
{
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
Log::Comment(L"-w 0 should always use the \"current\" window");
|
|
|
|
|
2021-02-22 19:50:39 +01:00
|
|
|
std::vector<winrt::hstring> args{ L"wt.exe", L"-w", L"0" };
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
auto result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseNew);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseCurrent, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
|
|
|
|
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseCurrent, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
|
|
|
|
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseAnyExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseCurrent, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
Log::Comment(L"-w last should always use the most recent window on "
|
|
|
|
L"this desktop");
|
|
|
|
|
|
|
|
std::vector<winrt::hstring> args{ L"wt.exe", L"-w", L"last" };
|
|
|
|
auto result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseNew);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseExisting, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseExisting, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseAnyExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseExisting, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
}
|
|
|
|
{
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
Log::Comment(L"Make sure we follow the provided argument when a "
|
|
|
|
L"--window-id wasn't explicitly provided");
|
|
|
|
|
2021-02-22 19:50:39 +01:00
|
|
|
std::vector<winrt::hstring> args{ L"wt.exe", L"new-tab" };
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
auto result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseNew);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
|
|
|
|
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseExisting, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
|
|
|
|
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseAnyExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseAnyExisting, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
Log::Comment(L"Even if someone uses a subcommand as a window name, "
|
|
|
|
L"that should work");
|
|
|
|
|
|
|
|
std::vector<winrt::hstring> args{ L"wt.exe", L"-w", L"new-tab" };
|
|
|
|
auto result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseNew);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseName, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"new-tab", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseName, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"new-tab", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseAnyExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseName, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"new-tab", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::TestFindTargetWindowHelp()
|
|
|
|
{
|
|
|
|
Log::Comment(L"--help should always create a new window");
|
|
|
|
|
|
|
|
// This is a little helper to make sure that these args _always_ return
|
|
|
|
// UseNew, regardless of the windowing behavior.
|
|
|
|
auto testHelper = [](auto&& args) {
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
auto result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseNew);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseAnyExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
testHelper(std::vector<winrt::hstring>{ L"wt.exe", L"--help" });
|
|
|
|
testHelper(std::vector<winrt::hstring>{ L"wt.exe", L"new-tab", L"--help" });
|
|
|
|
testHelper(std::vector<winrt::hstring>{ L"wt.exe", L"-w", L"0", L"new-tab", L"--help" });
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
testHelper(std::vector<winrt::hstring>{ L"wt.exe", L"-w", L"foo", L"new-tab", L"--help" });
|
2021-02-22 19:50:39 +01:00
|
|
|
testHelper(std::vector<winrt::hstring>{ L"wt.exe", L"new-tab", L";", L"--help" });
|
|
|
|
}
|
|
|
|
|
|
|
|
void CommandlineTest::TestFindTargetWindowVersion()
|
|
|
|
{
|
|
|
|
Log::Comment(L"--version should always create a new window");
|
|
|
|
|
|
|
|
// This is a little helper to make sure that these args _always_ return
|
|
|
|
// UseNew, regardless of the windowing behavior.
|
|
|
|
auto testHelper = [](auto&& args) {
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
auto result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseNew);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
|
Add support for naming windows with the `-w` parameter (#9300)
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
2021-03-17 20:28:01 +01:00
|
|
|
result = appImpl::AppLogic::_doFindTargetWindow({ args }, WindowingMode::UseAnyExisting);
|
|
|
|
VERIFY_ARE_EQUAL(WindowingBehaviorUseNew, result.WindowId());
|
|
|
|
VERIFY_ARE_EQUAL(L"", result.WindowName());
|
2021-02-22 19:50:39 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
testHelper(std::vector<winrt::hstring>{ L"wt.exe", L"--version" });
|
|
|
|
}
|
2020-01-27 16:34:12 +01:00
|
|
|
}
|