* Revert "Merge pull request #287668 from mjbvz/dev/mjbvz/eventual-sparrow"
This reverts commit 81f7af4b9f, reversing
changes made to 85a14f966c.
* Revert "Merge pull request #286642 from microsoft/dev/mjbvz/chat-session-item-controller"
This reverts commit b39ecc3960, reversing
changes made to 45aced5935.
This is a rethinking of the initial API proposed in `languageModelToolSupportsModel.d.ts`.
1. This switches to `models?: LanguageModelChatSelector[];` to control enablement.
definitely open to switching this out, but I think a synchronously-analyzable
expression is important to retain the data flows in core without too many races.
2. The extension is able to define a tool at runtime via registerToolDefinition. This
should let us have entirely service-driven tools from model providers without
requiring a static definition for each one. We can also have model-specific
variants of tools without a ton of package.json work for each variant of the tool
(as initially proposed using `when` clauses)
This then propagates that down into the tools service. Currently I have this as just
compiling to a `when` expression once it reaches the main thread. Then, for the tools
service, it takes an IContextKeyService in cases where tools should be enumerated,
and the chat input sets the model keys in its scoped context key service. This allows
the tools to be filtered correctly in the tool picker.
I initially thought about allowing multiple definitions be registered for the same tool
name/id for model-specific variants of tools but I realized that gets really gnarly and
we already have a `toolReferenceName` that multiple tools can register into.
Todo for tomorrow morning:
- Tools don't make it to the ChatRequest yet, or something, still need to investigate
- Need to make sure tools in prompts/models all work. For a first pass I think we can
let prompts/modes reference all tools by toolReferenceName.
- Validate that multiple tools actually can safely share a reference name (and do
some priority ordering?)
- General further validation
- Some unit tests
* Get chat session transferring working on the ChatSessionStore
* fix comment
* Fix tests, validate location
* Tests
* IChatTransferredSessionData is just a URI
* Fix leak
* api idea
* iterate
* start hacking
* wip
* use the right menu
* update
* update
* Fixes
* Fix test and override
---------
Co-authored-by: Connor Peet <connor@peet.io>
* Start work on using URIs to identify sessions
This starts switching us from id+types to use uris to identify chat sessions. I already added very basic support for this but in this next step I think we need a breaking change so that we can avoid adding more and more hacks and complexity to support this
* More work
* Add docs
* Fix indent
* Bump api
* Fix quotes
* Fix tests
* fix compile errors for mockChatSessionService
* Fix mockChatSessionService
* Update getChatSessionType
* Make sure resolver also registers any initial schemes
* add ChatSessionService.hasAnySessionOptions()
---------
Co-authored-by: Peng Lyu <penn.lv@gmail.com>
Co-authored-by: Josh Spicer <23246594+joshspicer@users.noreply.github.com>
For #269213
This adds a new eslint rule for `as any` and `<any>({... })`. We'd like to remove almost all of these, however right now the first goal is to prevent them in new code. That's why with this first PR I simply add `eslint-disable` comments for all breaks
Trying to get this change in soon after branching off for release to hopefully minimize disruption during debt week work
* adapt API to provide a chatParticipant
* initial tidy up to support agent in extension
* untitled prototype
* onDidCreateChatSessionIte
* tidy
* tidy
* names
* onDidCommitChatSessionItemEmitter and bump proposed api version
* deprecated note
* untitled with uuid to prevent collision
* pick correct editor group
* Add the ability to clear a ChatResponseStream, passing in a reason which results in a warning being displayed
* Changing ChatResponseStream.clear to ChatResponseStream.clearToPreviousToolInvocation and only clearing up to the last tool invocation
* Remove unnecessary code block
Co-authored-by: James Wang <120431051+jwangxx@users.noreply.github.com>
