In Profile.json we will define the actions section.
This section is an array and each element takes an Object, the schema can be
{
"icon" : "...",
"title" : "...",
"command": "..."
}
You can add an icon next to the icons at the top right and make the following features.
actions in Profile.json, it will create the elements of the list and execute a command when we click on it.
Edit : Where can we find a complete list of shortcut commands that we can use on the Windows-terminal? If there is no such place, is it possible to share in pdf or website form?
I think a list of common commands assigned to each profile, which displays as a toolbar, may be a better way. It also means the list of commands will be relevant to the profile, so no Bash commands while in Powershell.
I think a list of common commands assigned to each profile, which displays as a toolbar, may be a better way. It also means the list of commands will be relevant to the profile, so no Bash commands while in Powershell.
Are you talking about something like that? @mdtauk

I think a list of common commands assigned to each profile, which displays as a toolbar, may be a better way. It also means the list of commands will be relevant to the profile, so no Bash commands while in Powershell.
Are you talking about something like that? @mdtauk
Those actions/commands seem more suited to a context menu, as they are specific to the Windows Terminal - I was thinking something more like
"commands": [
{
"icon": "appx:\\icons\\windows.png",
"title": "WinVer",
"command": "winver.exe"
},
{
"icon": "appx:\\icons\\clear.png",
"title": "Clear Screen",
"command": "cls"
}
],
],
Would you want to duplicate the commands section per profile, or keep the icon/title the same in a central list but be able to conditionally show them based on environment or run different commands based on the environment (e.g. being able to specify cls for cmd and clear for WSL, and if you're in PS then it wouldn't appear).
Okay so this seems like it's getting close to a grab bag of feature requests. Lemme try and break this thread down so far:
Now, what I'll add is this immediately made me think of the Command Palette in VsCode and Sublime:

What if we added to that list:
Now, lets get into some nitty-gritty details. Lets stick to just the existing keybinding commands for now. If we wanted to later add a "inputCommand" keybinding we could, but I think that's definitely blocked on work in #1142 /#1349, where we can add an arbitrary commandline to the command. I'm also going to scope this discussion to have only a global list of actions. Keybindings are global only currently, so let's just make actions global too, and save per-profile keybindings and actions for another thread.
We could theoretically define default _actions_ for all the existing keybinding commands. With #754, we could add all the commands (that make sense) as actions to the actions list, so that everyone wouldn't need to define them manually.
An Action would be defined similarly to how you have it above:
class Action
{
winrt::hstring Name();
winrt::TerminalApp::ShortcutAction Command();
winrt::hstring IconPath();
}
We'd need another structure in GlobalAppSettings to hold all these actions. I guess it could just be a std::vector<Action> in GlobalAppSettings. We'll need to make sure to roundtrip serialize them. We'll need app to be able to turn this vector into a ListView or something of actions, so that it can display this list of actions. Each element in the view would need to be intrinsically associated with the Action object it's associated with. If Action isn't a winrt type, this might be a bit more painful, but it'll mean we'll need another class to do all the serializing of them, but that's a pattern we're already using so great. Action should be a winrt type: winrt::TerminalApp::Action (maybe needs a better name).
When an element is clicked on in the list of actions, we'll need to somehow raise the event corresponding to that ShortcutAction. AppKeyBindings already does a great job of dispatching ShortcutActions, so lets re-use that. We'll pull the basic parts of dispatching ShortcutAction callbacks into another class, ShortcutActionDispatch, with a single DoAction(ShortcutAction) (name WIP) method (and events for each action). AppKeybindings will be initialized with a reference to the ShortcutActionDispatch object, so that it can call DoAction on it.
In App, when someone clicks on an item in the list, we'll get the ShortcutAction associated with that list element, and call DoAction on the app's ShortcutActionDispatch.
</spec>
oh no I accidentally the whole thing

It's certainly not polished enough to ship how it is. We might not want to ship it at all in 1.0 honestly. It would need a lot of work, starting with polishing the above comment into a proper spec. But it's certainly super neat.
@zadjii-msft Any chance you could make a fork with that command palette as a branch so we can have a look at it?
@haydennyyy yea you can definitely check it out if you want, but it's buggy as heck ATM. The branch is dev/migrie/f/2046-command-palette
Cheers mate. :)
Heh, looking at all the commands you can now bind to keyboard shortcuts, had me thinking that yeah, WindowsTerminal needs something like VSCode's command palette.
From @xa0082249956 in #3879
User pressed Ctrl+Shift+Space, then focus moved to the Text Box automatically.
User typed
arc.
User typed
ipyinstead.
Well this looks damn epic
The prototype implementation of a command palette is exactly what I would be looking for. Hope to see this in a release soon!
One "wish for" I don't see in @zadjii-msft's mini-spec is a profile.json command to open a profile picker. For example, I'd like to create this binding:
{ "command": { "action": "${command:profilePicker}", "split": "horizontal", "profile": "PowerShell" }, "keys": "alt+shift+p" }
So when I press alt+shift+p to create a new horizontal split pane, I want to see this:

Then after I pick the profile I want, it opens in the new pane.
BTW "${command:profilePicker} is lifted straight from VSCode debug launch file syntax. Perhaps ${profilePicker} or just profilePicker would be sufficient for Windows Terminal.
@rkeithhill Oh, don't bother with that mini-spec anymore. There's far, _far_ more details in #5674 now 馃構
There's already plans to add support for dynamically adding commands for each of your profiles or color schemes.
Then, there's also #3586, which might let us specify in the profile param to both newTab and splitPane a way of prompting the user which profile they'd like to launch. Presumably, you could add a command then which boots a tab/pane directly to that prompt.
:tada:This issue was addressed in #6635, which has now been successfully released as Windows Terminal Preview v1.2.2022.0.:tada:
Handy links:
Most helpful comment
From @xa0082249956 in #3879