Disabled protocol handlers and registry updates on Windows in portable mode.
Added API proposal to detect if VS Code is running in portable mode from extensions.
Skipped protocol redirect in GitHub authentication in portable mode.
* chat: support representing file deletions in edit sessions
Add support for file deletion operations in chat editing sessions through
new ChatResponseWorkspaceEditPart. This allows agents to represent file-level
operations (deletions, creations, renames) alongside text and notebook edits.
- Adds ChatEditingDeletedFileEntry class to represent deleted files with
proper diff display and restoration functionality
- Introduces ChatResponseWorkspaceEditPart and IChatWorkspaceEdit interfaces
for file-level operations at the workspace level
- Implements workspace edit streaming through chat editing sessions with
proper undo/redo support
- Adds ChatWorkspaceEditContentPart for UI rendering of file operations
- Extends chat session storage to serialize deleted file entries
- Supports both acceptance and rejection of file deletions with proper state
management and snapshotting
Ref https://github.com/microsoft/vscode/issues/275705
(Commit message generated by Copilot)
* fix test
This reverts commit 17523c000e
Skips the api version bump this time since it's not needed
Breaking API change since `created` is now required but won't actually break at runtime
* 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>
