from my whiteboard notes

Right now, Terminal supports a couple built-in suggestion sources.

What if we allowed even more? What if we wanted arbitrary apps to be able to generate suggestions? Possible use cases:

• an app that synthesizes suggestions from your bash_history
• Something like Fig¹ / inshellisense
• an app that generates suggestions from commands.dev²
• Some LLM thing that generates suggestions based off the buffer
• A not contrived example: A 3p app that wants to manage credentials / PATs, but not store them in the Terminal directly. Thereby avoiding putting them on the clipboard too.³

How would we actually support this?

We could pretty easy use AppServiceConnections with apps that list themselves as Terminal extensions. Kinda like how we have apps that can say they're fragment extensions. We'd open an app service connection, pass them some state, then get a list of suggestions back. Yes, yes, ASC aren't great, but this kind of scenario is like, literally what they were made for.

We'd also need to make a couple changes to how the suggestions UI displays suggestions. Right now it's all done with actions, all at once. Then, we hand those actions over to the palette, and let it filter them. I've got a mind to do something else.

• What if all the suggestion sources were IAsyncAction<>s? We hand those asyncs to the suggestions control, then await them. When they're done handing back their actions, we put them into the suggestions list.
• Then, what if we didn't even have the suggestions control do the filtering itself? What if we passed the filter text to the extension?

• That would help support LLM scenarios, so users could type "how do I foo the frob" and the suggestion would be "foo --param frob.txt"
• We'd have to somehow be able to apply a weighting/ordering to these results uniformly. We could let extension authors give us that weight, but then it'll be a weighting arms race.

Lastly, permissions.

Similar to what I wrote in https://github.com/microsoft/terminal/blob/dev/migrie/s/ai-providers/doc/specs/drafts/LLM/Terminal-AI-Extensions.md

We'll need to present to users a number of settings to control how much context plugins are able to receive from the Terminal.

• Currently selected text
• Currently typed commandline
• Most recent (N) command(s)
  • and errorlevels
  • and output
• Environment variables
• profile commandline(?) (we may want to always provide the target exe, without args, as a bare min)
• Other panes too?

and we (terminal) need to store which things the user allowed in a separate, secure location. If the user disables permissions to a particular piece of data, then we need to either give the extension null (to explicitly indicate that it was rejected) or garbage data (the "ron swanson" option, don't even let the extension know that the permission was rejected)

Overall, it's a lot of work, and needs a long spec.

xlinks:

• Scenario: Add support for 3rd-party extensions #4000
• Enhance shell autocompletion with a cool new user interface and shell completion protocol #3121