2019-08-17 00:43:51 +02:00
|
|
|
// Copyright (c) Microsoft Corporation.
|
|
|
|
// Licensed under the MIT license.
|
|
|
|
|
|
|
|
#include "pch.h"
|
|
|
|
|
|
|
|
#include "ActionArgs.h"
|
|
|
|
|
|
|
|
#include "ActionEventArgs.g.cpp"
|
Add support for new panes with specifc profiles and other settings overrides (#3825)
## Summary of the Pull Request
This enables the user to set a number of extra settings in the `NewTab` and `SplitPane` `ShortcutAction`s, that enable customizing how a new terminal is created at runtime. The following four properties were added:
* `profile`
* `commandline`
* `tabTitle`
* `startingDirectory`
`profile` can be used with either a GUID or the name of a profile, and the action will launch that profile instead of the default.
`commandline`, `tabTitle`, and `startingDirectory` can all be used to override the profile's values of those settings. This will be more useful for #607.
With this PR, you can make bindings like the following:
```json
{ "keys": ["ctrl+a"], "command": { "action": "splitPane", "split": "vertical" } },
{ "keys": ["ctrl+b"], "command": { "action": "splitPane", "split": "vertical", "profile": "{6239a42c-1111-49a3-80bd-e8fdd045185c}" } },
{ "keys": ["ctrl+c"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile1" } },
{ "keys": ["ctrl+d"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile2" } },
{ "keys": ["ctrl+e"], "command": { "action": "splitPane", "split": "horizontal", "commandline": "foo.exe" } },
{ "keys": ["ctrl+f"], "command": { "action": "splitPane", "split": "horizontal", "profile": "profile1", "commandline": "foo.exe" } },
{ "keys": ["ctrl+g"], "command": { "action": "newTab" } },
{ "keys": ["ctrl+h"], "command": { "action": "newTab", "startingDirectory": "c:\\foo" } },
{ "keys": ["ctrl+i"], "command": { "action": "newTab", "profile": "profile2", "startingDirectory": "c:\\foo" } },
{ "keys": ["ctrl+j"], "command": { "action": "newTab", "tabTitle": "bar" } },
{ "keys": ["ctrl+k"], "command": { "action": "newTab", "profile": "profile2", "tabTitle": "bar" } },
{ "keys": ["ctrl+l"], "command": { "action": "newTab", "profile": "profile1", "tabTitle": "bar", "startingDirectory": "c:\\foo", "commandline":"foo.exe" } }
```
## References
This is a lot of work that was largely started in pursuit of #607. We want people to be able to override these properties straight from the commandline. While they may not make as much sense as keybindings like this, they'll make more sense as commandline arguments.
## PR Checklist
* [x] Closes #998
* [x] I work here
* [x] Tests added/passed
* [x] Requires documentation to be updated
## Validation Steps Performed
There are tests 🎉
Manually added some bindings, they opened the correct profiles in panes/tabs
2019-12-09 14:02:29 +01:00
|
|
|
#include "NewTerminalArgs.g.cpp"
|
2019-08-17 00:43:51 +02:00
|
|
|
#include "CopyTextArgs.g.cpp"
|
Add support for arbitrary args in keybindings (#3391)
## Summary of the Pull Request
Enables the user to provide arbitrary argument values to shortcut actions through a new `args` member of keybindings. For some keybindings, like `NewTabWithProfile<N>`, we previously needed 9 different `ShortcutAction`s, one for each value of `Index`. If a user wanted to have a `NewTabWithProfile11` keybinding, that was simply impossible. Now that the args are in their own separate json object, each binding can accept any number of arbitrary argument values.
So instead of:
```json
{ "command": "newTab", "keys": ["ctrl+shift+t"] },
{ "command": "newTabProfile0", "keys": ["ctrl+shift+1"] },
{ "command": "newTabProfile1", "keys": ["ctrl+shift+2"] },
{ "command": "newTabProfile2", "keys": ["ctrl+shift+3"] },
{ "command": "newTabProfile3", "keys": ["ctrl+shift+4"] },
```
We can now use:
```json
{ "command": "newTab", "keys": ["ctrl+shift+t"] },
{ "command": { "action": "newTab", "index": 0 }, "keys": ["ctrl+shift+1"] },
{ "command": { "action": "newTab", "index": 1 }, "keys": ["ctrl+shift+2"] },
{ "command": { "action": "newTab", "index": 2 }, "keys": ["ctrl+shift+3"] },
```
Initially, this does seem more verbose. However, for cases where there are multiple args, or there's a large range of values for the args, this will quickly become a more powerful system of expressing keybindings.
The "legacy" keybindings are _left in_ in this PR. They have helper methods to generate appropriate `IActionArgs` values. Prior to releasing 1.0, I think we should remove them, if only to remove some code bloat.
## References
See [the spec](https://github.com/microsoft/terminal/blob/master/doc/specs/%231142%20-%20Keybinding%20Arguments.md) for more details.
This is part two of the implementation, part one was #2446
## PR Checklist
* [x] Closes #1142
* [x] I work here
* [x] Tests added/passed
* [x] Schema updated
## Validation Steps Performed
* Ran Tests
* Removed the legacy keybindings from the `defaults.json`, everything still works
* Tried leaving the legacy keybingings in my `profiles.json`, everything still works.
-------------------------------------------------
* this is a start, but there's a weird linker bug if I take the SetKeybinding(ShortcutAction, KeyChord) implementation out, which I don't totally understand
* a good old-fashioned clean will fix that right up
* all these things work
* hey this actually _functionally_ works
* Mostly cleanup and completion of implementation
* Hey I bet we could just make NewTab the handler for NewTabWithProfile
* Start writing tests for Keybinding args
* Add tests
* Revert a bad sln change, and clean out dead code
* Change to include "command" as a single object
This is a change to make @dhowett-msft happy. Changes the args to be a part
of the "command" object, as opposed to an object on their own.
EX:
```jsonc
// Old style
{ "command": "switchToTab0", "keys": ["ctrl+1"] },
{ "command": { "action": "switchToTab", "index": 0 }, "keys": ["ctrl+alt+1"] },
// new style
{ "command": "switchToTab0", "keys": ["ctrl+1"] },
{ "command": "switchToTab", "args": { "index": 0 } "keys": ["ctrl+alt+1"] },
```
* schemas are hard yo
* Fix the build?
* wonder why my -Wall settings are different than CI...
* this makes me hate things
* Comments from PR
* Add a `Direction::None`
* LOAD BEARING
* add some GH ids to TODOs
* add a comment
* PR nits from carlos
2019-11-14 23:23:40 +01:00
|
|
|
#include "NewTabArgs.g.cpp"
|
2019-08-17 00:43:51 +02:00
|
|
|
#include "SwitchToTabArgs.g.cpp"
|
|
|
|
#include "ResizePaneArgs.g.cpp"
|
|
|
|
#include "MoveFocusArgs.g.cpp"
|
2019-09-30 15:18:05 +02:00
|
|
|
#include "AdjustFontSizeArgs.g.cpp"
|
2020-08-12 15:46:53 +02:00
|
|
|
#include "SendInputArgs.g.cpp"
|
2019-11-28 14:42:15 +01:00
|
|
|
#include "SplitPaneArgs.g.cpp"
|
Add keybinding arg to openSettings (#6299)
## Summary of the Pull Request
Adds the `target` keybinding arg to `openSettings`. Possible values include: `defaultsFile`, `settingsFile`, and `allFiles`.
## References
#5915 - mini-spec
## PR Checklist
* [x] Closes #2557
* [x] Tests added/passed
## Detailed Description of the Pull Request / Additional comments
Implemented as discussed in the attached spec. A new enum will be added for the SettingsUI when it becomes available.
## Validation Steps Performed
Added the following to my settings.json:
```json
{ "command": "openSettings", "keys":... },
{ "command": { "action": "openSettings" }, "keys":... },
{ "command": { "action": "openSettings", "target": "settingsFile" }, "keys":... },
{ "command": { "action": "openSettings", "target": "defaultsFile" }, "keys":... },
{ "command": { "action": "openSettings", "target": "allFiles" }, "keys":... }
```
2020-06-12 23:19:18 +02:00
|
|
|
#include "OpenSettingsArgs.g.cpp"
|
2020-08-10 18:21:56 +02:00
|
|
|
#include "SetColorSchemeArgs.g.cpp"
|
Add `setTabColor` and `openTabColorPicker` actions (#6567)
## Summary of the Pull Request
Adds a pair of `ShortcutAction`s for setting the tab color.
* `setTabColor`: This changes the color of the current tab to the provided color, or can be used to clear the color.
* `openTabColorPicker`: This keybinding immediately activates the tab color picker for the currently focused tab.
## References
## PR Checklist
* [x] scratches my own itch
* [x] I work here
* [x] Tests added/passed
* [x] https://github.com/MicrosoftDocs/terminal/pull/69
## Detailed Description of the Pull Request / Additional comments
## Validation Steps Performed
* hey look there are tests
* Tested with the following:
```json
// { "command": "setTabColor", "keys": [ "alt+c" ] },
{ "keys": "ctrl+alt+c", "command": { "action": "setTabColor", "color": "#123456" } },
{ "keys": "alt+shift+c", "command": { "action": "setTabColor", "color": null} },
{ "keys": "alt+c", "command": "openTabColorPicker" },
```
2020-06-25 15:06:21 +02:00
|
|
|
#include "SetTabColorArgs.g.cpp"
|
2020-06-24 22:07:41 +02:00
|
|
|
#include "RenameTabArgs.g.cpp"
|
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 "ExecuteCommandlineArgs.g.cpp"
|
2020-10-15 13:40:44 +02:00
|
|
|
#include "CloseOtherTabsArgs.g.cpp"
|
|
|
|
#include "CloseTabsAfterArgs.g.cpp"
|
2020-11-25 23:09:27 +01:00
|
|
|
#include "MoveTabArgs.g.cpp"
|
Add `findNext`, `findPrev` actions (#8917)
This PR is a resurrection of #8522. @Hegunumo has apparently deleted
their account, but the contribution was still valuable. I'm just here to
get it across the finish line.
This PR adds new action for navigating to the next & previous search
results. These actions are unbound by default. These actions can be used
from directly within the search dialog also, to immediately navigate the
results.
Furthermore, if you have a search started, and close the search box,
then press this keybinding, _it will still perform the search_. So you
can just hit <kbd>F3</kbd> repeatedly with the dialog closed to keep
searching new results. Neat!
If you dispatch the action on the key down, then dismiss a selection on
a key up, we'll end up immediately destroying the selection when you
release the bound key. That's annoying. It also bothers @carlos-zamora
in #3758. However, I _think_ we can just only dismiss the selection on a
key up. I _think_ that's fine. It _seems_ fine so far. We've got an
entire release cycle to futz with it.
## Validation Steps Performed
I've played with it all day and it seems _crisp_.
Closes #7695
Co-authored-by: Kiminori Kaburagi <yukawa_hidenori@icloud.com>
2021-02-18 20:21:35 +01:00
|
|
|
#include "FindMatchArgs.g.cpp"
|
2020-12-03 17:15:31 +01:00
|
|
|
#include "ToggleCommandPaletteArgs.g.cpp"
|
2021-02-20 00:51:30 +01:00
|
|
|
#include "NewWindowArgs.g.cpp"
|
Allow overriding tab switcher mode on command level (#9507)
## Summary of the Pull Request
Currently, when the MRU is enabled we lose the keybinding allowing us to
go forward/backward (aka right/left in LTR) in the tab view.
To fix that, this PR introduces "tabSwitcherMode" optional parameter to
the prevTab / nextTab commands.
If it is not provided the global setting will be used.
So if you want to go to adjacent tabs, even if MRU is enabled on the
system level you can use:
```
{ "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"}
```
or even
```
{"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"}
```
if you don't want tab switcher to show up
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/9330
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated - not yet. Waiting for approval.
* [x] Schema updated.
* [ ] I've discussed this with core contributors already.
2021-03-23 23:00:07 +01:00
|
|
|
#include "PrevTabArgs.g.cpp"
|
|
|
|
#include "NextTabArgs.g.cpp"
|
Add support for renaming windows (#9662)
## Summary of the Pull Request
This PR adds support for renaming windows.
![window-renaming-000](https://user-images.githubusercontent.com/18356694/113034344-9a30be00-9157-11eb-9443-975f3c294f56.gif)
![window-renaming-001](https://user-images.githubusercontent.com/18356694/113034452-b5033280-9157-11eb-9e35-e5ac80fef0bc.gif)
It does so through two new actions:
* `renameWindow` takes a `name` parameter, and attempts to set the window's name
to the provided name. This is useful if you always want to hit <kbd>F3</kbd>
and rename a window to "foo" (READ: probably not that useful)
* `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a
`TextBox`. When the user hits Ok, it'll request a rename for the provided
value. This lets the user pick a new name for the window at runtime.
In both cases, if there's already a window with that name, then the monarch will
reject the rename, and pop a `Toast` in the window informing the user that the
rename failed. Nifty!
## References
* Builds on the toasts from #9523
* #5000 - process model megathread
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747
* [x] I work here
* [x] Tests addded (and pass with the help of #9660)
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews.
> PAIN: We can't immediately focus the textbox in the TeachingTip. It's
> not technically focusable until it is opened. However, it doesn't
> provide an even tto tell us when it is opened. That's tracked in
> microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to
> click on the text box manually.
> We're also not using a ContentDialog for this, because in Xaml
> Islands a text box in a ContentDialog won't recieve _any_ keypresses.
> Fun!
## Validation Steps Performed
I've been playing with
```json
{ "keys": "f1", "command": "identifyWindow" },
{ "keys": "f2", "command": "identifyWindows" },
{ "keys": "f3", "command": "openWindowRenamer" },
{ "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } },
{ "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } },
```
and they seem to work as expected
2021-04-02 18:00:04 +02:00
|
|
|
#include "RenameWindowArgs.g.cpp"
|
2020-06-26 22:38:02 +02:00
|
|
|
|
|
|
|
#include <LibraryResources.h>
|
|
|
|
|
2021-03-17 21:47:24 +01:00
|
|
|
using namespace winrt::Microsoft::Terminal::Control;
|
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
|
|
|
|
2020-10-06 18:56:59 +02:00
|
|
|
namespace winrt::Microsoft::Terminal::Settings::Model::implementation
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
|
|
|
winrt::hstring NewTerminalArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
std::wstringstream ss;
|
|
|
|
|
|
|
|
if (!_Profile.empty())
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"profile: {}, ", _Profile);
|
|
|
|
}
|
|
|
|
else if (_ProfileIndex)
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"profile index: {}, ", _ProfileIndex.Value());
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!_Commandline.empty())
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"commandline: {}, ", _Commandline);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!_StartingDirectory.empty())
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"directory: {}, ", _StartingDirectory);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!_TabTitle.empty())
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"title: {}, ", _TabTitle);
|
|
|
|
}
|
2020-11-20 05:36:18 +01:00
|
|
|
|
|
|
|
if (_TabColor)
|
|
|
|
{
|
|
|
|
const til::color tabColor{ _TabColor.Value() };
|
|
|
|
ss << fmt::format(L"tabColor: {}, ", tabColor.ToHexString(true));
|
|
|
|
}
|
2021-03-29 22:04:39 +02:00
|
|
|
if (!_ColorScheme.empty())
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"colorScheme: {}, ", _ColorScheme);
|
|
|
|
}
|
2020-11-20 05:36:18 +01:00
|
|
|
|
2021-03-08 16:23:50 +01:00
|
|
|
if (_SuppressApplicationTitle)
|
|
|
|
{
|
|
|
|
if (_SuppressApplicationTitle.Value())
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"suppress application title, ");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"use application title, ");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
auto s = ss.str();
|
|
|
|
if (s.empty())
|
|
|
|
{
|
|
|
|
return L"";
|
|
|
|
}
|
|
|
|
|
|
|
|
// Chop off the last ", "
|
|
|
|
return winrt::hstring{ s.substr(0, s.size() - 2) };
|
|
|
|
}
|
|
|
|
|
2021-02-20 00:51:30 +01:00
|
|
|
winrt::hstring NewTerminalArgs::ToCommandline() const
|
|
|
|
{
|
|
|
|
std::wstringstream ss;
|
|
|
|
|
|
|
|
if (!_Profile.empty())
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"--profile \"{}\" ", _Profile);
|
|
|
|
}
|
|
|
|
// The caller is always expected to provide the evaluated profile in the
|
|
|
|
// NewTerminalArgs, not the index
|
|
|
|
//
|
|
|
|
// else if (_ProfileIndex)
|
|
|
|
// {
|
|
|
|
// ss << fmt::format(L"profile index: {}, ", _ProfileIndex.Value());
|
|
|
|
// }
|
|
|
|
|
|
|
|
if (!_StartingDirectory.empty())
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"--startingDirectory \"{}\" ", _StartingDirectory);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!_TabTitle.empty())
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"--title \"{}\" ", _TabTitle);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (_TabColor)
|
|
|
|
{
|
|
|
|
const til::color tabColor{ _TabColor.Value() };
|
|
|
|
ss << fmt::format(L"--tabColor \"{}\" ", tabColor.ToHexString(true));
|
|
|
|
}
|
|
|
|
|
2021-03-08 16:23:50 +01:00
|
|
|
if (_SuppressApplicationTitle)
|
|
|
|
{
|
|
|
|
if (_SuppressApplicationTitle.Value())
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"--suppressApplicationTitle ");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"--useApplicationTitle ");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-03-29 22:04:39 +02:00
|
|
|
if (!_ColorScheme.empty())
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"--colorScheme \"{}\" ", _ColorScheme);
|
|
|
|
}
|
|
|
|
|
2021-02-20 00:51:30 +01:00
|
|
|
if (!_Commandline.empty())
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"-- \"{}\" ", _Commandline);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto s = ss.str();
|
|
|
|
if (s.empty())
|
|
|
|
{
|
|
|
|
return L"";
|
|
|
|
}
|
|
|
|
|
|
|
|
// Chop off the last " "
|
|
|
|
return winrt::hstring{ s.substr(0, s.size() - 1) };
|
|
|
|
}
|
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
winrt::hstring CopyTextArgs::GenerateName() const
|
|
|
|
{
|
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
|
|
|
std::wstringstream ss;
|
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
if (_SingleLine)
|
|
|
|
{
|
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
|
|
|
ss << RS_(L"CopyTextAsSingleLineCommandKey").c_str();
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
ss << RS_(L"CopyTextCommandKey").c_str();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (_CopyFormatting != nullptr)
|
|
|
|
{
|
|
|
|
ss << L", copyFormatting: ";
|
|
|
|
if (_CopyFormatting.Value() == CopyFormat::All)
|
|
|
|
{
|
|
|
|
ss << L"all, ";
|
|
|
|
}
|
|
|
|
else if (_CopyFormatting.Value() == static_cast<CopyFormat>(0))
|
|
|
|
{
|
|
|
|
ss << L"none, ";
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (WI_IsFlagSet(_CopyFormatting.Value(), CopyFormat::HTML))
|
|
|
|
{
|
|
|
|
ss << L"html, ";
|
|
|
|
}
|
|
|
|
|
|
|
|
if (WI_IsFlagSet(_CopyFormatting.Value(), CopyFormat::RTF))
|
|
|
|
{
|
|
|
|
ss << L"rtf, ";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Chop off the last ","
|
|
|
|
auto result = ss.str();
|
|
|
|
return winrt::hstring{ result.substr(0, result.size() - 2) };
|
|
|
|
}
|
|
|
|
|
|
|
|
return winrt::hstring{ ss.str() };
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring NewTabArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
winrt::hstring newTerminalArgsStr;
|
|
|
|
if (_TerminalArgs)
|
|
|
|
{
|
|
|
|
newTerminalArgsStr = _TerminalArgs.GenerateName();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (newTerminalArgsStr.empty())
|
|
|
|
{
|
|
|
|
return RS_(L"NewTabCommandKey");
|
|
|
|
}
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(L"{}, {}", RS_(L"NewTabCommandKey"), newTerminalArgsStr)
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring SwitchToTabArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(L"{}, index:{}", RS_(L"SwitchToTabCommandKey"), _TabIndex)
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring ResizePaneArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
winrt::hstring directionString;
|
Support for navigating panes by MRU (#8183)
Adds a "move to previous pane" and "move to next pane" keybinding, which
navigates to the last/first focused pane
We assign pane IDs on creation and maintain a vector of active pane IDs
in MRU order. Navigating panes by MRU then requires specifying which
pane ID we want to focus.
From our offline discussion (thanks @zadjii-msft for the concise
description):
> For the record, the full spec I'm imagining is:
>
> { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } },
>
> and order defaults to mru, and useSwitcher will default to true, when
> there is a switcher. So
>
> { command": { "action": "focusNextPane" } },
> { command": { "action": "focusNextPane", "order": "mru" } },
>
> these are the same action. (but right now we don't support the order
> param)
>
> Then there'll be another PR for "focusPane(target=id)"
>
> Then a third PR for "focus(Next|Prev)Pane(order=inOrder)"
> for the record, I prefer this approach over the "one action to rule
> them all" version with both target and order/direction as params,
> because I don't like the confusion of what happens if there's both
> target and order/direction provided.
References #1000
Closes #2871
2020-12-11 19:36:05 +01:00
|
|
|
switch (_ResizeDirection)
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
Support for navigating panes by MRU (#8183)
Adds a "move to previous pane" and "move to next pane" keybinding, which
navigates to the last/first focused pane
We assign pane IDs on creation and maintain a vector of active pane IDs
in MRU order. Navigating panes by MRU then requires specifying which
pane ID we want to focus.
From our offline discussion (thanks @zadjii-msft for the concise
description):
> For the record, the full spec I'm imagining is:
>
> { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } },
>
> and order defaults to mru, and useSwitcher will default to true, when
> there is a switcher. So
>
> { command": { "action": "focusNextPane" } },
> { command": { "action": "focusNextPane", "order": "mru" } },
>
> these are the same action. (but right now we don't support the order
> param)
>
> Then there'll be another PR for "focusPane(target=id)"
>
> Then a third PR for "focus(Next|Prev)Pane(order=inOrder)"
> for the record, I prefer this approach over the "one action to rule
> them all" version with both target and order/direction as params,
> because I don't like the confusion of what happens if there's both
> target and order/direction provided.
References #1000
Closes #2871
2020-12-11 19:36:05 +01:00
|
|
|
case ResizeDirection::Left:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionLeft");
|
|
|
|
break;
|
Support for navigating panes by MRU (#8183)
Adds a "move to previous pane" and "move to next pane" keybinding, which
navigates to the last/first focused pane
We assign pane IDs on creation and maintain a vector of active pane IDs
in MRU order. Navigating panes by MRU then requires specifying which
pane ID we want to focus.
From our offline discussion (thanks @zadjii-msft for the concise
description):
> For the record, the full spec I'm imagining is:
>
> { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } },
>
> and order defaults to mru, and useSwitcher will default to true, when
> there is a switcher. So
>
> { command": { "action": "focusNextPane" } },
> { command": { "action": "focusNextPane", "order": "mru" } },
>
> these are the same action. (but right now we don't support the order
> param)
>
> Then there'll be another PR for "focusPane(target=id)"
>
> Then a third PR for "focus(Next|Prev)Pane(order=inOrder)"
> for the record, I prefer this approach over the "one action to rule
> them all" version with both target and order/direction as params,
> because I don't like the confusion of what happens if there's both
> target and order/direction provided.
References #1000
Closes #2871
2020-12-11 19:36:05 +01:00
|
|
|
case ResizeDirection::Right:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionRight");
|
|
|
|
break;
|
Support for navigating panes by MRU (#8183)
Adds a "move to previous pane" and "move to next pane" keybinding, which
navigates to the last/first focused pane
We assign pane IDs on creation and maintain a vector of active pane IDs
in MRU order. Navigating panes by MRU then requires specifying which
pane ID we want to focus.
From our offline discussion (thanks @zadjii-msft for the concise
description):
> For the record, the full spec I'm imagining is:
>
> { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } },
>
> and order defaults to mru, and useSwitcher will default to true, when
> there is a switcher. So
>
> { command": { "action": "focusNextPane" } },
> { command": { "action": "focusNextPane", "order": "mru" } },
>
> these are the same action. (but right now we don't support the order
> param)
>
> Then there'll be another PR for "focusPane(target=id)"
>
> Then a third PR for "focus(Next|Prev)Pane(order=inOrder)"
> for the record, I prefer this approach over the "one action to rule
> them all" version with both target and order/direction as params,
> because I don't like the confusion of what happens if there's both
> target and order/direction provided.
References #1000
Closes #2871
2020-12-11 19:36:05 +01:00
|
|
|
case ResizeDirection::Up:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionUp");
|
|
|
|
break;
|
Support for navigating panes by MRU (#8183)
Adds a "move to previous pane" and "move to next pane" keybinding, which
navigates to the last/first focused pane
We assign pane IDs on creation and maintain a vector of active pane IDs
in MRU order. Navigating panes by MRU then requires specifying which
pane ID we want to focus.
From our offline discussion (thanks @zadjii-msft for the concise
description):
> For the record, the full spec I'm imagining is:
>
> { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } },
>
> and order defaults to mru, and useSwitcher will default to true, when
> there is a switcher. So
>
> { command": { "action": "focusNextPane" } },
> { command": { "action": "focusNextPane", "order": "mru" } },
>
> these are the same action. (but right now we don't support the order
> param)
>
> Then there'll be another PR for "focusPane(target=id)"
>
> Then a third PR for "focus(Next|Prev)Pane(order=inOrder)"
> for the record, I prefer this approach over the "one action to rule
> them all" version with both target and order/direction as params,
> because I don't like the confusion of what happens if there's both
> target and order/direction provided.
References #1000
Closes #2871
2020-12-11 19:36:05 +01:00
|
|
|
case ResizeDirection::Down:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionDown");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"ResizePaneWithArgCommandKey")),
|
|
|
|
directionString)
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring MoveFocusArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
winrt::hstring directionString;
|
Support for navigating panes by MRU (#8183)
Adds a "move to previous pane" and "move to next pane" keybinding, which
navigates to the last/first focused pane
We assign pane IDs on creation and maintain a vector of active pane IDs
in MRU order. Navigating panes by MRU then requires specifying which
pane ID we want to focus.
From our offline discussion (thanks @zadjii-msft for the concise
description):
> For the record, the full spec I'm imagining is:
>
> { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } },
>
> and order defaults to mru, and useSwitcher will default to true, when
> there is a switcher. So
>
> { command": { "action": "focusNextPane" } },
> { command": { "action": "focusNextPane", "order": "mru" } },
>
> these are the same action. (but right now we don't support the order
> param)
>
> Then there'll be another PR for "focusPane(target=id)"
>
> Then a third PR for "focus(Next|Prev)Pane(order=inOrder)"
> for the record, I prefer this approach over the "one action to rule
> them all" version with both target and order/direction as params,
> because I don't like the confusion of what happens if there's both
> target and order/direction provided.
References #1000
Closes #2871
2020-12-11 19:36:05 +01:00
|
|
|
switch (_FocusDirection)
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
Support for navigating panes by MRU (#8183)
Adds a "move to previous pane" and "move to next pane" keybinding, which
navigates to the last/first focused pane
We assign pane IDs on creation and maintain a vector of active pane IDs
in MRU order. Navigating panes by MRU then requires specifying which
pane ID we want to focus.
From our offline discussion (thanks @zadjii-msft for the concise
description):
> For the record, the full spec I'm imagining is:
>
> { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } },
>
> and order defaults to mru, and useSwitcher will default to true, when
> there is a switcher. So
>
> { command": { "action": "focusNextPane" } },
> { command": { "action": "focusNextPane", "order": "mru" } },
>
> these are the same action. (but right now we don't support the order
> param)
>
> Then there'll be another PR for "focusPane(target=id)"
>
> Then a third PR for "focus(Next|Prev)Pane(order=inOrder)"
> for the record, I prefer this approach over the "one action to rule
> them all" version with both target and order/direction as params,
> because I don't like the confusion of what happens if there's both
> target and order/direction provided.
References #1000
Closes #2871
2020-12-11 19:36:05 +01:00
|
|
|
case FocusDirection::Left:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionLeft");
|
|
|
|
break;
|
Support for navigating panes by MRU (#8183)
Adds a "move to previous pane" and "move to next pane" keybinding, which
navigates to the last/first focused pane
We assign pane IDs on creation and maintain a vector of active pane IDs
in MRU order. Navigating panes by MRU then requires specifying which
pane ID we want to focus.
From our offline discussion (thanks @zadjii-msft for the concise
description):
> For the record, the full spec I'm imagining is:
>
> { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } },
>
> and order defaults to mru, and useSwitcher will default to true, when
> there is a switcher. So
>
> { command": { "action": "focusNextPane" } },
> { command": { "action": "focusNextPane", "order": "mru" } },
>
> these are the same action. (but right now we don't support the order
> param)
>
> Then there'll be another PR for "focusPane(target=id)"
>
> Then a third PR for "focus(Next|Prev)Pane(order=inOrder)"
> for the record, I prefer this approach over the "one action to rule
> them all" version with both target and order/direction as params,
> because I don't like the confusion of what happens if there's both
> target and order/direction provided.
References #1000
Closes #2871
2020-12-11 19:36:05 +01:00
|
|
|
case FocusDirection::Right:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionRight");
|
|
|
|
break;
|
Support for navigating panes by MRU (#8183)
Adds a "move to previous pane" and "move to next pane" keybinding, which
navigates to the last/first focused pane
We assign pane IDs on creation and maintain a vector of active pane IDs
in MRU order. Navigating panes by MRU then requires specifying which
pane ID we want to focus.
From our offline discussion (thanks @zadjii-msft for the concise
description):
> For the record, the full spec I'm imagining is:
>
> { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } },
>
> and order defaults to mru, and useSwitcher will default to true, when
> there is a switcher. So
>
> { command": { "action": "focusNextPane" } },
> { command": { "action": "focusNextPane", "order": "mru" } },
>
> these are the same action. (but right now we don't support the order
> param)
>
> Then there'll be another PR for "focusPane(target=id)"
>
> Then a third PR for "focus(Next|Prev)Pane(order=inOrder)"
> for the record, I prefer this approach over the "one action to rule
> them all" version with both target and order/direction as params,
> because I don't like the confusion of what happens if there's both
> target and order/direction provided.
References #1000
Closes #2871
2020-12-11 19:36:05 +01:00
|
|
|
case FocusDirection::Up:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionUp");
|
|
|
|
break;
|
Support for navigating panes by MRU (#8183)
Adds a "move to previous pane" and "move to next pane" keybinding, which
navigates to the last/first focused pane
We assign pane IDs on creation and maintain a vector of active pane IDs
in MRU order. Navigating panes by MRU then requires specifying which
pane ID we want to focus.
From our offline discussion (thanks @zadjii-msft for the concise
description):
> For the record, the full spec I'm imagining is:
>
> { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } },
>
> and order defaults to mru, and useSwitcher will default to true, when
> there is a switcher. So
>
> { command": { "action": "focusNextPane" } },
> { command": { "action": "focusNextPane", "order": "mru" } },
>
> these are the same action. (but right now we don't support the order
> param)
>
> Then there'll be another PR for "focusPane(target=id)"
>
> Then a third PR for "focus(Next|Prev)Pane(order=inOrder)"
> for the record, I prefer this approach over the "one action to rule
> them all" version with both target and order/direction as params,
> because I don't like the confusion of what happens if there's both
> target and order/direction provided.
References #1000
Closes #2871
2020-12-11 19:36:05 +01:00
|
|
|
case FocusDirection::Down:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionDown");
|
|
|
|
break;
|
Support for navigating panes by MRU (#8183)
Adds a "move to previous pane" and "move to next pane" keybinding, which
navigates to the last/first focused pane
We assign pane IDs on creation and maintain a vector of active pane IDs
in MRU order. Navigating panes by MRU then requires specifying which
pane ID we want to focus.
From our offline discussion (thanks @zadjii-msft for the concise
description):
> For the record, the full spec I'm imagining is:
>
> { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } },
>
> and order defaults to mru, and useSwitcher will default to true, when
> there is a switcher. So
>
> { command": { "action": "focusNextPane" } },
> { command": { "action": "focusNextPane", "order": "mru" } },
>
> these are the same action. (but right now we don't support the order
> param)
>
> Then there'll be another PR for "focusPane(target=id)"
>
> Then a third PR for "focus(Next|Prev)Pane(order=inOrder)"
> for the record, I prefer this approach over the "one action to rule
> them all" version with both target and order/direction as params,
> because I don't like the confusion of what happens if there's both
> target and order/direction provided.
References #1000
Closes #2871
2020-12-11 19:36:05 +01:00
|
|
|
case FocusDirection::Previous:
|
|
|
|
return RS_(L"MoveFocusToLastUsedPane");
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"MoveFocusWithArgCommandKey")),
|
|
|
|
directionString)
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring AdjustFontSizeArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// If the amount is just 1 (or -1), we'll just return "Increase font
|
|
|
|
// size" (or "Decrease font size"). If the amount delta has a greater
|
|
|
|
// absolute value, we'll include it like"
|
|
|
|
// * Decrease font size, amount: {delta}"
|
|
|
|
if (_Delta < 0)
|
|
|
|
{
|
|
|
|
return _Delta == -1 ? RS_(L"DecreaseFontSizeCommandKey") :
|
|
|
|
winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"DecreaseFontSizeWithAmountCommandKey")),
|
|
|
|
-_Delta)
|
|
|
|
};
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
return _Delta == 1 ? RS_(L"IncreaseFontSizeCommandKey") :
|
|
|
|
winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"IncreaseFontSizeWithAmountCommandKey")),
|
|
|
|
_Delta)
|
|
|
|
};
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-08-12 15:46:53 +02:00
|
|
|
winrt::hstring SendInputArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// The string will be similar to the following:
|
|
|
|
// * "Send Input: ...input..."
|
|
|
|
|
2020-10-06 18:56:59 +02:00
|
|
|
auto escapedInput = til::visualize_control_codes(_Input);
|
2020-08-12 15:46:53 +02:00
|
|
|
auto name = fmt::format(std::wstring_view(RS_(L"SendInputCommandKey")), escapedInput);
|
|
|
|
return winrt::hstring{ name };
|
|
|
|
}
|
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
winrt::hstring SplitPaneArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// The string will be similar to the following:
|
Add `size` param to `splitPane` action, `split-pane` subcommand (#8543)
## Summary of the Pull Request
Adds a `size` parameter to `splitPane`. This takes a `float`, and specifies the portion of the parent pane that should be used to create the new one.
This also adds the param to the `split-pane` subcommand.
### Examples
| commandline | result |
| -- | -- |
| `wt ; sp -s .25` | ![image](https://user-images.githubusercontent.com/18356694/101784317-fb595680-3ac0-11eb-8248-782dc61957cf.png) |
| `wt ; sp -s .8` | ![image](https://user-images.githubusercontent.com/18356694/101784442-20e66000-3ac1-11eb-8f9b-fb45a73c9334.png) |
| `wt ; sp -s .8 ; sp -H -s .3` | ![image](https://user-images.githubusercontent.com/18356694/101784552-470c0000-3ac1-11eb-9deb-df37aaa36f01.png) |
## PR Checklist
* [x] Closes #6298
* [x] I work here
* [x] Tests added/passed
* [x] Docs PR: MicrosoftDocs/terminal#208
## Detailed Description of the Pull Request / Additional comments
I went with `size`, `--size,-s` rather than `percent`, because the arg is the (0,1) version of the size, not the (0%,100%) version.
## Validation Steps Performed
Added actions, played with the commandline, ran tests
2020-12-18 04:51:53 +01:00
|
|
|
// * "Duplicate pane[, split: <direction>][, size: <size>%][, new terminal arguments...]"
|
|
|
|
// * "Split pane[, split: <direction>][, size: <size>%][, new terminal arguments...]"
|
2020-06-26 22:38:02 +02:00
|
|
|
//
|
|
|
|
// Direction will only be added to the string if the split direction is
|
|
|
|
// not "auto".
|
|
|
|
// If this is a "duplicate pane" action, then the new terminal arguments
|
|
|
|
// will be omitted (as they're unused)
|
|
|
|
|
|
|
|
std::wstringstream ss;
|
|
|
|
if (_SplitMode == SplitType::Duplicate)
|
|
|
|
{
|
|
|
|
ss << std::wstring_view(RS_(L"DuplicatePaneCommandKey"));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
ss << std::wstring_view(RS_(L"SplitPaneCommandKey"));
|
|
|
|
}
|
|
|
|
ss << L", ";
|
|
|
|
|
|
|
|
// This text is intentionally _not_ localized, to attempt to mirror the
|
|
|
|
// exact syntax that the property would have in JSON.
|
|
|
|
switch (_SplitStyle)
|
|
|
|
{
|
|
|
|
case SplitState::Vertical:
|
|
|
|
ss << L"split: vertical, ";
|
|
|
|
break;
|
|
|
|
case SplitState::Horizontal:
|
|
|
|
ss << L"split: horizontal, ";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
Add `size` param to `splitPane` action, `split-pane` subcommand (#8543)
## Summary of the Pull Request
Adds a `size` parameter to `splitPane`. This takes a `float`, and specifies the portion of the parent pane that should be used to create the new one.
This also adds the param to the `split-pane` subcommand.
### Examples
| commandline | result |
| -- | -- |
| `wt ; sp -s .25` | ![image](https://user-images.githubusercontent.com/18356694/101784317-fb595680-3ac0-11eb-8248-782dc61957cf.png) |
| `wt ; sp -s .8` | ![image](https://user-images.githubusercontent.com/18356694/101784442-20e66000-3ac1-11eb-8f9b-fb45a73c9334.png) |
| `wt ; sp -s .8 ; sp -H -s .3` | ![image](https://user-images.githubusercontent.com/18356694/101784552-470c0000-3ac1-11eb-9deb-df37aaa36f01.png) |
## PR Checklist
* [x] Closes #6298
* [x] I work here
* [x] Tests added/passed
* [x] Docs PR: MicrosoftDocs/terminal#208
## Detailed Description of the Pull Request / Additional comments
I went with `size`, `--size,-s` rather than `percent`, because the arg is the (0,1) version of the size, not the (0%,100%) version.
## Validation Steps Performed
Added actions, played with the commandline, ran tests
2020-12-18 04:51:53 +01:00
|
|
|
if (_SplitSize != .5f)
|
|
|
|
{
|
|
|
|
ss << L"size: " << (_SplitSize * 100) << L"%, ";
|
|
|
|
}
|
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
winrt::hstring newTerminalArgsStr;
|
|
|
|
if (_TerminalArgs)
|
|
|
|
{
|
|
|
|
newTerminalArgsStr = _TerminalArgs.GenerateName();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (_SplitMode != SplitType::Duplicate && !newTerminalArgsStr.empty())
|
|
|
|
{
|
|
|
|
ss << newTerminalArgsStr.c_str();
|
|
|
|
ss << L", ";
|
|
|
|
}
|
|
|
|
|
|
|
|
// Chop off the last ", "
|
|
|
|
auto s = ss.str();
|
|
|
|
return winrt::hstring{ s.substr(0, s.size() - 2) };
|
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring OpenSettingsArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
switch (_Target)
|
|
|
|
{
|
|
|
|
case SettingsTarget::DefaultsFile:
|
|
|
|
return RS_(L"OpenDefaultSettingsCommandKey");
|
|
|
|
case SettingsTarget::AllFiles:
|
|
|
|
return RS_(L"OpenBothSettingsFilesCommandKey");
|
2021-02-24 01:14:13 +01:00
|
|
|
case SettingsTarget::SettingsFile:
|
|
|
|
return RS_(L"OpenSettingsCommandKey");
|
2021-01-04 23:14:51 +01:00
|
|
|
case SettingsTarget::SettingsUI:
|
2020-06-26 22:38:02 +02:00
|
|
|
default:
|
2021-02-24 01:14:13 +01:00
|
|
|
return RS_(L"OpenSettingsUICommandKey");
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-08-10 18:21:56 +02:00
|
|
|
winrt::hstring SetColorSchemeArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// "Set color scheme to "{_SchemeName}""
|
|
|
|
if (!_SchemeName.empty())
|
|
|
|
{
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"SetColorSchemeCommandKey")),
|
|
|
|
_SchemeName.c_str())
|
|
|
|
};
|
|
|
|
}
|
|
|
|
return L"";
|
|
|
|
}
|
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
winrt::hstring SetTabColorArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// "Set tab color to #RRGGBB"
|
|
|
|
// "Reset tab color"
|
|
|
|
if (_TabColor)
|
|
|
|
{
|
2020-11-20 05:36:18 +01:00
|
|
|
til::color tabColor{ _TabColor.Value() };
|
2020-06-26 22:38:02 +02:00
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"SetTabColorCommandKey")),
|
2020-11-20 05:36:18 +01:00
|
|
|
tabColor.ToHexString(true))
|
2020-06-26 22:38:02 +02:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
return RS_(L"ResetTabColorCommandKey");
|
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring RenameTabArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// "Rename tab to \"{_Title}\""
|
|
|
|
// "Reset tab title"
|
|
|
|
if (!_Title.empty())
|
|
|
|
{
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"RenameTabCommandKey")),
|
|
|
|
_Title.c_str())
|
|
|
|
};
|
|
|
|
}
|
|
|
|
return RS_(L"ResetTabNameCommandKey");
|
|
|
|
}
|
|
|
|
|
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
|
|
|
winrt::hstring ExecuteCommandlineArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// "Run commandline "{_Commandline}" in this window"
|
|
|
|
if (!_Commandline.empty())
|
|
|
|
{
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"ExecuteCommandlineCommandKey")),
|
|
|
|
_Commandline.c_str())
|
|
|
|
};
|
|
|
|
}
|
|
|
|
return L"";
|
|
|
|
}
|
|
|
|
|
2020-08-06 23:47:50 +02:00
|
|
|
winrt::hstring CloseOtherTabsArgs::GenerateName() const
|
|
|
|
{
|
2020-08-25 21:25:25 +02:00
|
|
|
if (_Index)
|
|
|
|
{
|
|
|
|
// "Close tabs other than index {0}"
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"CloseOtherTabsCommandKey")),
|
|
|
|
_Index.Value())
|
|
|
|
};
|
|
|
|
}
|
|
|
|
return RS_(L"CloseOtherTabsDefaultCommandKey");
|
2020-08-06 23:47:50 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring CloseTabsAfterArgs::GenerateName() const
|
|
|
|
{
|
2020-08-25 21:25:25 +02:00
|
|
|
if (_Index)
|
|
|
|
{
|
|
|
|
// "Close tabs after index {0}"
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"CloseTabsAfterCommandKey")),
|
|
|
|
_Index.Value())
|
|
|
|
};
|
|
|
|
}
|
|
|
|
return RS_(L"CloseTabsAfterDefaultCommandKey");
|
2020-08-06 23:47:50 +02:00
|
|
|
}
|
2020-10-27 02:19:52 +01:00
|
|
|
|
|
|
|
winrt::hstring ScrollUpArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
if (_RowsToScroll)
|
|
|
|
{
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"ScrollUpSeveralRowsCommandKey")),
|
|
|
|
_RowsToScroll.Value())
|
|
|
|
};
|
|
|
|
}
|
|
|
|
return RS_(L"ScrollUpCommandKey");
|
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring ScrollDownArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
if (_RowsToScroll)
|
|
|
|
{
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"ScrollDownSeveralRowsCommandKey")),
|
|
|
|
_RowsToScroll.Value())
|
|
|
|
};
|
|
|
|
}
|
|
|
|
return RS_(L"ScrollDownCommandKey");
|
|
|
|
}
|
2020-11-25 23:09:27 +01:00
|
|
|
|
|
|
|
winrt::hstring MoveTabArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
winrt::hstring directionString;
|
|
|
|
switch (_Direction)
|
|
|
|
{
|
|
|
|
case MoveTabDirection::Forward:
|
|
|
|
directionString = RS_(L"MoveTabDirectionForward");
|
|
|
|
break;
|
|
|
|
case MoveTabDirection::Backward:
|
|
|
|
directionString = RS_(L"MoveTabDirectionBackward");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"MoveTabCommandKey")),
|
|
|
|
directionString)
|
|
|
|
};
|
|
|
|
}
|
2020-12-03 17:15:31 +01:00
|
|
|
|
|
|
|
winrt::hstring ToggleCommandPaletteArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
if (_LaunchMode == CommandPaletteLaunchMode::CommandLine)
|
|
|
|
{
|
|
|
|
return RS_(L"ToggleCommandPaletteCommandLineModeCommandKey");
|
|
|
|
}
|
|
|
|
return RS_(L"ToggleCommandPaletteCommandKey");
|
|
|
|
}
|
Add `findNext`, `findPrev` actions (#8917)
This PR is a resurrection of #8522. @Hegunumo has apparently deleted
their account, but the contribution was still valuable. I'm just here to
get it across the finish line.
This PR adds new action for navigating to the next & previous search
results. These actions are unbound by default. These actions can be used
from directly within the search dialog also, to immediately navigate the
results.
Furthermore, if you have a search started, and close the search box,
then press this keybinding, _it will still perform the search_. So you
can just hit <kbd>F3</kbd> repeatedly with the dialog closed to keep
searching new results. Neat!
If you dispatch the action on the key down, then dismiss a selection on
a key up, we'll end up immediately destroying the selection when you
release the bound key. That's annoying. It also bothers @carlos-zamora
in #3758. However, I _think_ we can just only dismiss the selection on a
key up. I _think_ that's fine. It _seems_ fine so far. We've got an
entire release cycle to futz with it.
## Validation Steps Performed
I've played with it all day and it seems _crisp_.
Closes #7695
Co-authored-by: Kiminori Kaburagi <yukawa_hidenori@icloud.com>
2021-02-18 20:21:35 +01:00
|
|
|
|
|
|
|
winrt::hstring FindMatchArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
switch (_Direction)
|
|
|
|
{
|
|
|
|
case FindMatchDirection::Next:
|
|
|
|
return winrt::hstring{ RS_(L"FindNextCommandKey") };
|
|
|
|
case FindMatchDirection::Previous:
|
|
|
|
return winrt::hstring{ RS_(L"FindPrevCommandKey") };
|
|
|
|
}
|
|
|
|
return L"";
|
|
|
|
}
|
2021-02-20 00:51:30 +01:00
|
|
|
|
|
|
|
winrt::hstring NewWindowArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
winrt::hstring newTerminalArgsStr;
|
|
|
|
if (_TerminalArgs)
|
|
|
|
{
|
|
|
|
newTerminalArgsStr = _TerminalArgs.GenerateName();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (newTerminalArgsStr.empty())
|
|
|
|
{
|
|
|
|
return RS_(L"NewWindowCommandKey");
|
|
|
|
}
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(L"{}, {}", RS_(L"NewWindowCommandKey"), newTerminalArgsStr)
|
|
|
|
};
|
|
|
|
}
|
Allow overriding tab switcher mode on command level (#9507)
## Summary of the Pull Request
Currently, when the MRU is enabled we lose the keybinding allowing us to
go forward/backward (aka right/left in LTR) in the tab view.
To fix that, this PR introduces "tabSwitcherMode" optional parameter to
the prevTab / nextTab commands.
If it is not provided the global setting will be used.
So if you want to go to adjacent tabs, even if MRU is enabled on the
system level you can use:
```
{ "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"}
```
or even
```
{"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"}
```
if you don't want tab switcher to show up
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/9330
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated - not yet. Waiting for approval.
* [x] Schema updated.
* [ ] I've discussed this with core contributors already.
2021-03-23 23:00:07 +01:00
|
|
|
|
|
|
|
winrt::hstring PrevTabArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
if (!_SwitcherMode)
|
|
|
|
{
|
|
|
|
return RS_(L"PrevTabCommandKey");
|
|
|
|
}
|
|
|
|
|
|
|
|
const auto mode = _SwitcherMode.Value() == TabSwitcherMode::MostRecentlyUsed ? L"most recently used" : L"in order";
|
|
|
|
return winrt::hstring(fmt::format(L"{}, {}", RS_(L"PrevTabCommandKey"), mode));
|
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring NextTabArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
if (!_SwitcherMode)
|
|
|
|
{
|
|
|
|
return RS_(L"NextTabCommandKey");
|
|
|
|
}
|
|
|
|
|
|
|
|
const auto mode = _SwitcherMode.Value() == TabSwitcherMode::MostRecentlyUsed ? L"most recently used" : L"in order";
|
|
|
|
return winrt::hstring(fmt::format(L"{}, {}", RS_(L"NextTabCommandKey"), mode));
|
|
|
|
}
|
Add support for renaming windows (#9662)
## Summary of the Pull Request
This PR adds support for renaming windows.
![window-renaming-000](https://user-images.githubusercontent.com/18356694/113034344-9a30be00-9157-11eb-9443-975f3c294f56.gif)
![window-renaming-001](https://user-images.githubusercontent.com/18356694/113034452-b5033280-9157-11eb-9e35-e5ac80fef0bc.gif)
It does so through two new actions:
* `renameWindow` takes a `name` parameter, and attempts to set the window's name
to the provided name. This is useful if you always want to hit <kbd>F3</kbd>
and rename a window to "foo" (READ: probably not that useful)
* `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a
`TextBox`. When the user hits Ok, it'll request a rename for the provided
value. This lets the user pick a new name for the window at runtime.
In both cases, if there's already a window with that name, then the monarch will
reject the rename, and pop a `Toast` in the window informing the user that the
rename failed. Nifty!
## References
* Builds on the toasts from #9523
* #5000 - process model megathread
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747
* [x] I work here
* [x] Tests addded (and pass with the help of #9660)
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews.
> PAIN: We can't immediately focus the textbox in the TeachingTip. It's
> not technically focusable until it is opened. However, it doesn't
> provide an even tto tell us when it is opened. That's tracked in
> microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to
> click on the text box manually.
> We're also not using a ContentDialog for this, because in Xaml
> Islands a text box in a ContentDialog won't recieve _any_ keypresses.
> Fun!
## Validation Steps Performed
I've been playing with
```json
{ "keys": "f1", "command": "identifyWindow" },
{ "keys": "f2", "command": "identifyWindows" },
{ "keys": "f3", "command": "openWindowRenamer" },
{ "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } },
{ "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } },
```
and they seem to work as expected
2021-04-02 18:00:04 +02:00
|
|
|
|
|
|
|
winrt::hstring RenameWindowArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// "Rename window to \"{_Name}\""
|
|
|
|
// "Clear window name"
|
|
|
|
if (!_Name.empty())
|
|
|
|
{
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"RenameWindowCommandKey")),
|
|
|
|
_Name.c_str())
|
|
|
|
};
|
|
|
|
}
|
|
|
|
return RS_(L"ResetWindowNameCommandKey");
|
|
|
|
}
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|