maxmustermann/terminal
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
terminal/src/cascadia/LocalTests_TerminalApp/CommandlineTest.cpp

2081 lines
103 KiB
C++
Raw Normal View History

Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "pch.h"
#include <WexTestClass.h>
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
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"
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
2021-02-22 19:50:39 +01:00
#include "../TerminalApp/AppLogic.h"
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
#include "../TerminalApp/AppCommandlineArgs.h"
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
2021-02-22 19:50:39 +01:00
#include "../inc/WindowingBehavior.h"
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
using namespace WEX::Logging;
using namespace WEX::Common;
using namespace WEX::TestExecution;
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
2021-02-22 19:50:39 +01:00
using namespace winrt;
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
using namespace winrt::Microsoft::Terminal::Settings::Model;
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
using namespace winrt::TerminalApp;
using namespace ::TerminalApp;
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
2021-02-22 19:50:39 +01:00
namespace winrt
{
namespace appImpl = TerminalApp::implementation;
}
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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);
Configure CLI11 to stuff all unknown positionals into the cmdli… (#4388) This commit fixes an issue where "wt -d C: wsl -d Alpine" would be parsed as "wt -d C: -d Alpine wsl" and rejected as invalid due to the repeated -d. It also fixes support for the option parsing terminator, --, in all command lines. Fixes #4277.
2020-01-29 22:01:05 +01:00
TEST_METHOD(ParseArgumentsWithParsingTerminators);
Add support for `focusPane` action, `focus-pane` subcommand (#10142) ## Summary of the Pull Request Adds support for the `focusPane` action, and the `focus-pane` subcommand. These allow the user to focus a pane by it's ID. * `focusPane` accepts an `id`, identifying the id of the pane to focus. * `focus-pane`, `fp` requires the parameter `--target,-t` to ID the pane it's going to focus. ## PR Checklist * [x] Closes #5803 * [x] Closes #5464 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - oh no ## Detailed Description of the Pull Request / Additional comments The ID isn't _totally_ useful right now, since users can't see them. But they're there, and used in-order. This is just slightly more ergonomic for complicated commandlines than `mf up; mf left` ## Validation Steps Performed Tested in command palette Tested a variety of commandlines. `wtd -w 0 mf down ; sp` and `wtd -w 0 fp -t 1 ; sp` gave me special difficulty.
2021-05-21 23:55:57 +02:00
TEST_METHOD(ParseFocusPaneArgs);
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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);
7124: Add focus and maximizedFocus launch modes (#7873) This commit introduces two new launch modes: focus and maximizedFocus. * Focused mode, behaves like a default mode, but with the Focus Mode enabled. * Maximized focused mode, behaves like a Maximized mode, but with the Focus Mode enabled. There two ways to invoke these new modes: * In the settings file: you set the "launchMode" to either "focus" or "maximizedFocus" * In the command line options, you can path -f / --focus, which is mutually exclusive with the --fullscreen, but can be combined with the --maximized: * Passing -f / --focus will launch the terminal in the "focus" mode * Passing -fM / --focus --maximized will launch the terminal in the "maximizedFocus" mode This should resolve a relevant part in the command line arguments mega-thread #4632 Closes #7124 Closes #7825 Closes #7875
2020-10-15 00:19:51 +02:00
TEST_METHOD(TestLaunchMode);
Fix combining wt args and "wt new-tab" args in implicit context (#8315) Currently when implicit tab command is specified (i.e., we have parameters for new-tab, but don't have the explicit subcommand name) we fallback to parsing the entire arg list as new tab command. However, if we also have a launch profile (or anything else that might in the future belong to the upper scope) it is passed as a parameter to the new tab command, failing the parsing. The idea behind my solution is to run the parser as a prefix command - i.e., as long as we succeed to parse [options] / [subcommand] we will parse them (populating the fields like a launch mode), but once we will discover something unfamiliar, like profile, we will know that the prefix is over and will handle the remaining suffix as a new tab command. ## Validation Steps Performed * UT added * Manual run of different options Closes #7318
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
Reset the `size` param between `split-pane` subcommands (#8753) ## Summary of the Pull Request I forgot to reset the `--size` argument to `split-pane` when I added it. This PR fixes that, and adds a test so I don't regress it again. ## References * Missed in #8543 ## PR Checklist * [x] I work here * [x] Tests added/passed
2021-01-13 00:19:55 +01:00
TEST_METHOD(TestMultipleSplitPaneSizes);
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
2021-02-22 19:50:39 +01:00
TEST_METHOD(TestFindTargetWindow);
TEST_METHOD(TestFindTargetWindowHelp);
TEST_METHOD(TestFindTargetWindowVersion);
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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()));
}
}
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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";
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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 };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
2021-03-29 22:04:39 +02:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
VERIFY_IS_FALSE(myArgs.TerminalArgs().Profile().empty());
VERIFY_ARE_EQUAL(L"cmd", myArgs.TerminalArgs().Profile());
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
2021-03-29 22:04:39 +02:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
VERIFY_ARE_EQUAL(L"c:\\Foo", myArgs.TerminalArgs().StartingDirectory());
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
2021-03-29 22:04:39 +02:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().Profile().empty());
VERIFY_ARE_EQUAL(L"powershell.exe", myArgs.TerminalArgs().Commandline());
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
2021-03-29 22:04:39 +02:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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);
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
2021-03-29 22:04:39 +02:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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);
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
2021-03-29 22:04:39 +02:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
VERIFY_IS_FALSE(myArgs.TerminalArgs().Profile().empty());
VERIFY_ARE_EQUAL(L"Windows PowerShell", myArgs.TerminalArgs().Profile());
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
2021-03-29 22:04:39 +02:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
2021-03-29 22:04:39 +02:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
2021-03-29 22:04:39 +02:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
}
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
{
AppCommandlineArgs appArgs{};
std::vector<const wchar_t*> rawCommands{ L"wt.exe", subcommand, L"--tabColor", L"#009999" };
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
2021-02-22 19:50:39 +01:00
const auto expectedColor = ::Microsoft::Console::Utils::ColorFromHexString("#009999");
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
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());
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
}
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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";
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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 };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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);
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4340 * [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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
Add splitMode to the args for split-pane (as -D for duplicate) (#9652) Closes #9579
2021-03-30 00:06:05 +02:00
VERIFY_ARE_EQUAL(SplitType::Manual, myArgs.SplitMode());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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);
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4340 * [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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Down, myArgs.SplitDirection());
Add splitMode to the args for split-pane (as -D for duplicate) (#9652) Closes #9579
2021-03-30 00:06:05 +02:00
VERIFY_ARE_EQUAL(SplitType::Manual, myArgs.SplitMode());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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);
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4340 * [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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Right, myArgs.SplitDirection());
Add splitMode to the args for split-pane (as -D for duplicate) (#9652) Closes #9579
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());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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);
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4340 * [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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
2021-03-29 22:04:39 +02:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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);
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4340 * [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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Down, myArgs.SplitDirection());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
2021-03-29 22:04:39 +02:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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);
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4340 * [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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
2021-03-29 22:04:39 +02:00
VERIFY_IS_TRUE(myArgs.TerminalArgs().ColorScheme().empty());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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";
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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 };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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";
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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 };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
const auto actionAndArgs = appArgs._startupActions.at(1);
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
VERIFY_ARE_EQUAL(ShortcutAction::NextTab, actionAndArgs.Action());
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
const auto myArgs = actionAndArgs.Args().as<NextTabArgs>();
VERIFY_ARE_EQUAL(TabSwitcherMode::Disabled, myArgs.SwitcherMode().Value());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
VERIFY_IS_NOT_NULL(actionAndArgs.Args());
const auto myArgs = actionAndArgs.Args().as<PrevTabArgs>();
VERIFY_ARE_EQUAL(TabSwitcherMode::Disabled, myArgs.SwitcherMode().Value());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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"-t", L"2" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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);
Convert Tab to a WinRT type (#4350) ## Summary of the Pull Request This PR will make the existing `Tab` class into a WinRT type. This will allow any XAML to simply bind to the `ObservableVector` of Tabs. This PR will be followed up with a future PR to change our TabView to use the ObservableVector, which will in turn eliminate the need for maintaining two vectors of Tabs. (We currently maintain `_tabs` in `TerminalPage` and we also maintain `TabView().TabViewItems()` at the same time as described here: #2740) ## References #3922 ## PR Checklist * [x] CLA signed. * [x] Tests added/passed ## Detailed Description of the Pull Request / Additional comments I've currently only exposed a Tab's Title and IconPath to keep things simple. I foresee XAML elements that bind to Tabs to only really need these two properties for displaying. I've also converted `TerminalPage`'s `std::vector<std::shared_ptr> _tabs` into a `IObservableVector<winrt::TerminalPage::Tab> _tabs` just so that future PRs will have the ground set for binding to this vector of tabs. ## Validation Steps Performed Played around with Tabs and Panes and all sorts of combinations of keybindings for interacting with tabs and dragging and whatnot, it all seemed fine! Tab Tests also all pass.
2020-02-04 22:51:11 +01:00
VERIFY_ARE_EQUAL(static_cast<uint32_t>(2), myArgs.TabIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
}
}
Add support for `focusPane` action, `focus-pane` subcommand (#10142) ## Summary of the Pull Request Adds support for the `focusPane` action, and the `focus-pane` subcommand. These allow the user to focus a pane by it's ID. * `focusPane` accepts an `id`, identifying the id of the pane to focus. * `focus-pane`, `fp` requires the parameter `--target,-t` to ID the pane it's going to focus. ## PR Checklist * [x] Closes #5803 * [x] Closes #5464 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - oh no ## Detailed Description of the Pull Request / Additional comments The ID isn't _totally_ useful right now, since users can't see them. But they're there, and used in-order. This is just slightly more ergonomic for complicated commandlines than `mf up; mf left` ## Validation Steps Performed Tested in command palette Tested a variety of commandlines. `wtd -w 0 mf down ; sp` and `wtd -w 0 fp -t 1 ; sp` gave me special difficulty.
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());
}
}
}
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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 "
Configure CLI11 to stuff all unknown positionals into the cmdli… (#4388) This commit fixes an issue where "wt -d C: wsl -d Alpine" would be parsed as "wt -d C: -d Alpine wsl" and rejected as invalid due to the repeated -d. It also fixes support for the option parsing terminator, --, in all command lines. Fixes #4277.
2020-01-29 22:01:05 +01:00
L"be treated as a commandline"));
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
VERIFY_IS_NULL(myArgs.TerminalArgs().TabColor());
VERIFY_IS_NULL(myArgs.TerminalArgs().ProfileIndex());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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" };
Configure CLI11 to stuff all unknown positionals into the cmdli… (#4388) This commit fixes an issue where "wt -d C: wsl -d Alpine" would be parsed as "wt -d C: -d Alpine wsl" and rejected as invalid due to the repeated -d. It also fixes support for the option parsing terminator, --, in all command lines. Fixes #4277.
2020-01-29 22:01:05 +01:00
_buildCommandlinesHelper(appArgs, 1u, rawCommands);
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
Configure CLI11 to stuff all unknown positionals into the cmdli… (#4388) This commit fixes an issue where "wt -d C: wsl -d Alpine" would be parsed as "wt -d C: -d Alpine wsl" and rejected as invalid due to the repeated -d. It also fixes support for the option parsing terminator, --, in all command lines. Fixes #4277.
2020-01-29 22:01:05 +01:00
VERIFY_ARE_EQUAL(1u, appArgs._startupActions.size());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
Configure CLI11 to stuff all unknown positionals into the cmdli… (#4388) This commit fixes an issue where "wt -d C: wsl -d Alpine" would be parsed as "wt -d C: -d Alpine wsl" and rejected as invalid due to the repeated -d. It also fixes support for the option parsing terminator, --, in all command lines. Fixes #4277.
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());
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
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()
{
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
ExecuteCommandlineArgs args{ L"new-tab" };
Separate runtime TerminalSettings from profile-TerminalSettings (#8602) <!-- 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 The TerminalSettings object we create from profiles no longer gets passed into the control, instead, a child of that object gets passed into the control. Any overrides the control makes to the settings then live in the child. So, when we do a settings reload, we simply update the child's parent and the overrides will remain. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [ ] Closes #xxx * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] 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 * [ ] Schema updated. * [x] I work here <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
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()
{
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
ExecuteCommandlineArgs args{ L"new-tab ; split-pane" };
Separate runtime TerminalSettings from profile-TerminalSettings (#8602) <!-- 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 The TerminalSettings object we create from profiles no longer gets passed into the control, instead, a child of that object gets passed into the control. Any overrides the control makes to the settings then live in the child. So, when we do a settings reload, we simply update the child's parent and the overrides will remain. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [ ] Closes #xxx * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] 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 * [ ] Schema updated. * [x] I work here <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
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());
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
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.
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
ExecuteCommandlineArgs args{ L"split-pane -H -V" };
Separate runtime TerminalSettings from profile-TerminalSettings (#8602) <!-- 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 The TerminalSettings object we create from profiles no longer gets passed into the control, instead, a child of that object gets passed into the control. Any overrides the control makes to the settings then live in the child. So, when we do a settings reload, we simply update the child's parent and the overrides will remain. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [ ] Closes #xxx * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] 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 * [ ] Schema updated. * [x] I work here <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing
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());
}
7124: Add focus and maximizedFocus launch modes (#7873) This commit introduces two new launch modes: focus and maximizedFocus. * Focused mode, behaves like a default mode, but with the Focus Mode enabled. * Maximized focused mode, behaves like a Maximized mode, but with the Focus Mode enabled. There two ways to invoke these new modes: * In the settings file: you set the "launchMode" to either "focus" or "maximizedFocus" * In the command line options, you can path -f / --focus, which is mutually exclusive with the --fullscreen, but can be combined with the --maximized: * Passing -f / --focus will launch the terminal in the "focus" mode * Passing -fM / --focus --maximized will launch the terminal in the "maximizedFocus" mode This should resolve a relevant part in the command line arguments mega-thread #4632 Closes #7124 Closes #7825 Closes #7875
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);
}
}
Fix combining wt args and "wt new-tab" args in implicit context (#8315) Currently when implicit tab command is specified (i.e., we have parameters for new-tab, but don't have the explicit subcommand name) we fallback to parsing the entire arg list as new tab command. However, if we also have a launch profile (or anything else that might in the future belong to the upper scope) it is passed as a parameter to the new tab command, failing the parsing. The idea behind my solution is to run the parser as a prefix command - i.e., as long as we succeed to parse [options] / [subcommand] we will parse them (populating the fields like a launch mode), but once we will discover something unfamiliar, like profile, we will know that the prefix is over and will handle the remaining suffix as a new tab command. ## Validation Steps Performed * UT added * Manual run of different options Closes #7318
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());
}
}
Reset the `size` param between `split-pane` subcommands (#8753) ## Summary of the Pull Request I forgot to reset the `--size` argument to `split-pane` when I added it. This PR fixes that, and adds a test so I don't regress it again. ## References * Missed in #8543 ## PR Checklist * [x] I work here * [x] Tests added/passed
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);
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4340 * [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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
Reset the `size` param between `split-pane` subcommands (#8753) ## Summary of the Pull Request I forgot to reset the `--size` argument to `split-pane` when I added it. This PR fixes that, and adds a test so I don't regress it again. ## References * Missed in #8543 ## PR Checklist * [x] I work here * [x] Tests added/passed
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);
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4340 * [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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
Reset the `size` param between `split-pane` subcommands (#8753) ## Summary of the Pull Request I forgot to reset the `--size` argument to `split-pane` when I added it. This PR fixes that, and adds a test so I don't regress it again. ## References * Missed in #8543 ## PR Checklist * [x] I work here * [x] Tests added/passed
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);
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4340 * [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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
Reset the `size` param between `split-pane` subcommands (#8753) ## Summary of the Pull Request I forgot to reset the `--size` argument to `split-pane` when I added it. This PR fixes that, and adds a test so I don't regress it again. ## References * Missed in #8543 ## PR Checklist * [x] I work here * [x] Tests added/passed
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);
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4340 * [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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
Reset the `size` param between `split-pane` subcommands (#8753) ## Summary of the Pull Request I forgot to reset the `--size` argument to `split-pane` when I added it. This PR fixes that, and adds a test so I don't regress it again. ## References * Missed in #8543 ## PR Checklist * [x] I work here * [x] Tests added/passed
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);
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4340 * [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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
Reset the `size` param between `split-pane` subcommands (#8753) ## Summary of the Pull Request I forgot to reset the `--size` argument to `split-pane` when I added it. This PR fixes that, and adds a test so I don't regress it again. ## References * Missed in #8543 ## PR Checklist * [x] I work here * [x] Tests added/passed
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);
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4340 * [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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Automatic, myArgs.SplitDirection());
Reset the `size` param between `split-pane` subcommands (#8753) ## Summary of the Pull Request I forgot to reset the `--size` argument to `split-pane` when I added it. This PR fixes that, and adds a test so I don't regress it again. ## References * Missed in #8543 ## PR Checklist * [x] I work here * [x] Tests added/passed
2021-01-13 00:19:55 +01:00
VERIFY_ARE_EQUAL(0.7f, myArgs.SplitSize());
VERIFY_IS_NOT_NULL(myArgs.TerminalArgs());
}
}
}
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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).");
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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");
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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");
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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");
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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");
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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" });
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
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());
Fix `wt --help` (#9246) When the user executes `--help`, make sure we force the creation of a new window, so that the `MessageBox` will actually appear. Add tests too. * [x] I work here * [x] Fixes #9230 * [x] Tests added I'm gonna have to immediately rewrite those tests for https://github.com/microsoft/terminal/projects/5#card-51431478, but this issue is ship-blocking so I don't care
2021-02-22 19:50:39 +01:00
};
testHelper(std::vector<winrt::hstring>{ L"wt.exe", L"--version" });
}
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
}
Reference in a new issue Copy permalink