New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request - Scripts Panel #1595
Comments
panes are comimg into the terminal soon, well its already within the code, its just unfinished |
Actually, I'm gonna re-open this. This is a not terrible idea for an extension, similar to #644 |
Adding some other comments from other duped threads: @ThatWionGuy in #5273:
_ @zadjii-msft in #5273 _:
_ @MrGolden1 in #11270 _:
|
The 'scripts panel' that starts this thread is great for indexing/retaining/invoking a massive library of scripts. Later suggestions are closer to my needs: frequently accessing a (more limited, but commonly used) set of commands or executables (batch files/shell scripts/python/etc.). I'd like to see one step further in terms of simplification (since UI elements is on the roadmap for extensions): a generic toolbar which contains 'buttons' that are linked to specific commands or executables. The profile structure suggested in #5273 could be extended to support the configuration of the toolbar (also add an 'icon' for quick & easy locating of specific buttons). I'm thinking the end result would be something akin to Chrome's 'Bookmarks' toolbar. Once defined, your favorite commands are one click away! As a next-level of difficulty, other elements could be added to add variability to toolbar items, such as a listbox to select one of several 'user profiles' when logging into ssh, or a textbox to enter a variable to pass on the command line to the script invoked by the associated button, etc. |
I think we've actually got a good mental model on the team (if albeit not formally communicated) of how this is going to end up working. We've got our plan for action ID's, and customizing the dropdown with those action IDs (#1571). The "bookmarks bar" would just be the same kind of thing, with different UI. It's just another place that users can bind actions to a button. So opening specific profiles, running commands, all those could be bound to those buttons. (see also #2934, #4531) Moving some relevant discussion from #6412:
|
Note to self: I'm gonna start using this thread for the "input actions" mode of the command palette. I've had notes all over, but I'm copying bits here for tracking
And then the many follow ups:
|
The Initial wireframes Look similar to what ist available in Warp (Warp Drive Workflows) https://docs.warp.dev/features/warp-drive/workflows Having These Concepts directly integrated into the terminal (ai as Well) feels really great! |
There's two parts to this PR that should be considered _separately_. 1. The Suggestions UI, a new graphical menu for displaying suggestions / completions to the user in the context of the terminal the user is working in. 2. The VsCode shell completions protocol. This enables the shell to invoke this UI via a VT sequence. These are being introduced at the same time, because they both require one another. However, I need to absolutely emphasize: ### THE FORMAT OF THE COMPLETION PROTOCOL IS EXPERIMENTAL AND SUBJECT TO CHANGE This is what we've prototyped with VsCode, but we're still working on how we want to conclusively define that protocol. However, we can also refine the Suggestions UI independently of how the protocol is actually implemented. This will let us rev the Suggestions UI to support other things like tooltips, recent commands, tasks, INDEPENDENTLY of us rev'ing the completion protocol. So yes, they're both here, but let's not nitpick that protocol for now. ### Checklist * Doesn't actually close anything * Heavily related to #3121, but I'm not gonna say that's closed till we settle on the protocol * See also: * #1595 * #14779 * microsoft/vscode#171648 ### Detailed Description #### Suggestions UI The Suggestions UI is spec'ed over in #14864, so go read that. It's basically a transient Command Palette, that floats by the user's cursor. It's heavily forked from the Command Palette code, with all the business about switching modes removed. The major bit of new code is `SuggestionsControl::Anchor`. It also supports two "modes": * A "palette", which is like the command palette - a list with a text box * A "menu", which is more like the intellisense flyout. No text box. This is the mode that the shell completions use #### Shell Completions Protocol I literally cannot say this enough times - this protocol is experimental and subject to change. Build on it at your own peril. It's disabled in Release builds (but available in preview behind `globals.experimental.enableShellCompletionMenu`), so that when it ships, no one can take a dependency on it accidentally. Right now we're just taking a blob of JSON, passing that up to the App layer, who asks `Command` to parse it and build a list of `sendInput` actions to populate the menu with. It's not a particularly elegant solution, but it's good enough to prototype with. #### How do I test this? I've been testing this in two parts. You'll need a snippet in your powershell profile, and a keybinding in the Terminal settings to trigger it. The work together by binding <kbd>Ctrl+space</kbd> to _essentially_ send <kbd>F12</kbd><kbd>b</kbd>. Wacky, but it works. ```json { "command": { "action": "sendInput","input": "\u001b[24~b" }, "keys": "ctrl+space" }, ``` ```ps1 function Send-Completions2 { $commandLine = "" $cursorIndex = 0 # TODO: Since fuzzy matching exists, should completions be provided only for character after the # last space and then filter on the client side? That would let you trigger ctrl+space # anywhere on a word and have full completions available [Microsoft.PowerShell.PSConsoleReadLine]::GetBufferState([ref]$commandLine, [ref]$cursorIndex) $completionPrefix = $commandLine # Get completions $result = "`e]633;Completions" if ($completionPrefix.Length -gt 0) { # Get and send completions $completions = TabExpansion2 -inputScript $completionPrefix -cursorColumn $cursorIndex if ($null -ne $completions.CompletionMatches) { $result += ";$($completions.ReplacementIndex);$($completions.ReplacementLength);$($cursorIndex);" $result += $completions.CompletionMatches | ConvertTo-Json -Compress } } $result += "`a" Write-Host -NoNewLine $result } function Set-MappedKeyHandlers { # VS Code send completions request (may override Ctrl+Spacebar) Set-PSReadLineKeyHandler -Chord 'F12,b' -ScriptBlock { Send-Completions2 } } # Register key handlers if PSReadLine is available if (Get-Module -Name PSReadLine) { Set-MappedKeyHandlers } ``` ### TODO * [x] `(prompt | format-hex).`<kbd>Ctrl+space</kbd> -> This always throws an exception. Seems like the payload is always clipped to ```{"CompletionText":"Ascii","ListItemText":"Ascii","ResultType":5,"ToolTip":"string Ascii { get``` and that ain't JSON. Investigate on the pwsh side?
_targets #15027_ Adds a new suggestion source, `tasks`, that allows a user to open the Suggestions UI with `sendInput` commands saved in their settings. `source` becomes a flag setting, so it can be combined like so: ```json { "keys": "ctrl+shift+h", "command": { "action": "suggestions", "source": "commandHistory", "useCommandline":true }, }, { "keys": "ctrl+shift+y", "command": { "action": "suggestions", "source": "tasks", "useCommandline":false }, }, { "keys": "ctrl+shift+b", "command": { "action": "suggestions", "source": ["all"], "useCommandline":true }, }, ``` If a nested command has `sendInput` commands underneath it, this will build a tree of commands that only include `sendInput`s as leaves (but leave the rest of the nesting structure intact). ## References and Relevant Issues Closes #1595 See also #13445 As spec'd in #14864 ## Validation Steps Performed Tested manually
## Summary of the Pull Request > ## Abstract > > Multiple related scenarios have come up where it would be beneficial to display > actionable UI to the user within the context of the active terminal itself. This > UI would be akin to the Intellisense UI in Visual Studio. It appears right where > the user is typing, and can help provide immediate content for the user, based > on some context. The "Suggestions UI" is this new ephemeral UI within the > Windows Terminal that can display different types of actions, from different > sources. > ## Detailed Description of the Pull Request / Additional comments _\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_ Similar to #14792, a lot of this code is written. This stuff isn't checked in though, so I'm presenting formally before I start yeeting PRs out there. ## PR Checklist - [x] This is a spec for #1595. It also references: * #3121 * #10436 * #12927 * #12863
Type the same commands multiple times or using external files from the terminal application to launch scripts. This feature would solve the problem of users alt tabbing allot of the time to run scripts where it could be in built in the terminal as an added option to make a side panel appear or something similar to that to show scripts and run them.
I want a panel to have toggle or an additional option so you can have a panel or something similar to be attached to the terminal so that you can run scripts from terminal and do not have to go into windows and search for scripts. This would kind of be like the the powershell ISE commands panel that you can toggle on but it would be for multiple terminals and you can set what you want to run their and the commands or scripts that you run all the time.
The text was updated successfully, but these errors were encountered: