Skip to content
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

Allow 3p suggestion sources #17344

Open
Tracked by #15845
zadjii-msft opened this issue May 31, 2024 · 1 comment
Open
Tracked by #15845

Allow 3p suggestion sources #17344

zadjii-msft opened this issue May 31, 2024 · 1 comment
Labels
Area-Extensibility A feature that would ideally be fulfilled by us having an extension model. Issue-Scenario Product-Terminal The new Windows Terminal.
Milestone

Comments

@zadjii-msft
Copy link
Member

zadjii-msft commented May 31, 2024

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 Fig1 / inshellisense
  • an app that generates suggestions from commands.dev2
  • 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.3

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:

Footnotes

  1. RIP

  2. sure this is contrived, because you can just do https://github.com/microsoft/terminal/blob/dev/migrie/s/snippets/doc/specs/%231595%20-%20Suggestions%20UI/dump-workflows.py, but the point stands

  3. this was specifically called out in a mail thread "Windows Terminal extensions?" from 5/13/2024

@zadjii-msft zadjii-msft added Area-Extensibility A feature that would ideally be fulfilled by us having an extension model. Product-Terminal The new Windows Terminal. Issue-Scenario labels May 31, 2024
@zadjii-msft zadjii-msft added this to the Backlog milestone May 31, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label May 31, 2024
@peterwie
Copy link

peterwie commented Jun 3, 2024

the ability to connect my console up to my password manager in a secure way sounds terrific. I think it would help remove one of the remaining reasons that people use weak passwords.

@carlos-zamora carlos-zamora removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Extensibility A feature that would ideally be fulfilled by us having an extension model. Issue-Scenario Product-Terminal The new Windows Terminal.
Projects
None yet
Development

No branches or pull requests

3 participants