Recent commands UI #14779
Labels
Area-Settings
Issues related to settings and customizability, for console or terminal
In-PR
This issue has a related PR
Issue-Task
It's a feature request, but it doesn't really need a major design.
Needs-Tag-Fix
Doesn't match tag requirements
Product-Terminal
The new Windows Terminal.
Milestone
Comments
KyodaiKen
added
the
Issue-Feature
microsoft-github-policy-service
bot
added
Needs-Triage
|
Sorry, this is just something that's got to be a feature of the shell ( Now I had an idea in mind that might help mitigate this. It'd be a little wonky, but it would persist your command history regardless of shell. And since I don't really have a thread I'm already using for tracking that, I'm tempted to hijack this thread for that purpose. My solution wouldn't be a CLI feature - it'd be build directly into the Terminal, and the history would be exposed via a UI element in the Terminal. You okay with me re-purposing this thread? x-link #13445 |
|
That sounds nice! I actually proposed to add it to the Terminal app itself, I wouldn't have posted it here. You can of course hijack this thread. Let's see how it goes! |
zadjii-msft
added
Area-Settings
microsoft-github-policy-service
bot
removed
the
Needs-Tag-Fix
This was referenced Mar 1, 2023
zadjii-msft
added a commit
that referenced
this issue
Aug 14, 2023
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?
zadjii-msft
added a commit
that referenced
this issue
Aug 15, 2023
This adds support for a new action, `showSuggestions`, as described in #14864. This adds just one `source` currently, `recentCommands`. This requires shell integration to be enabled in the shell to work properly. When it is enabled, activating that action will invoke the suggestions UI as a palette, populated with `sendInput` actions for each of the user's recent commands. * These don't persist across reboots. * These are per-control. There's mild plans to remedy that in a follow-up, though that needs a bit more design consideration. Closes #14779
microsoft-github-policy-service
bot
added
the
Needs-Tag-Fix
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the new feature/enhancement
In Linux, almost every terminal stores a persistent history of commands. I think in this case it's the interpreter like
bashorzsh. But I think it should be possible to do it on app level per user as well.Proposed technical implementation details (optional)
A simple SQLite DB file per user and per command interpreter (cmd, powershell, etc.) that stores the history of commands could be used. The location should be configurable in the preferences JSON.
User enters:
User closes terminal and maybe even reboots windows
User opens terminal back up and can push the arrow up key to recall the last commands they have executed.
User cannot find what they're searching for, so they type:
And sees a list like this:
And can redo the command using
!1or!0.With
#0the line pops up to be edited before executing with theRETURNkeyThe text was updated successfully, but these errors were encountered: