JS/TS can return a lot of completions. I noticed that just parsing this was taking a bit of time, so I tried to reduce the message size with the following changes:
- Inline the command properties on `ISuggestDataDto`
- Drop the `title` and `tooltip` from the command since we don't use these
- Shorten the delegate command name
- If using an `$ident` command, don't send over the command arguments since the arguments are always `[$ident]`
- Make commit characters a string instead of an array
Here's an example of a dto for a completion item before:
```
{"x":[2,0],"a":"$","b":4,"e":"15","i":0,"k":[".",",",";","("],"m":{"$ident":867,"id":"_vscode_delegate_cmd_l9g7z48t","title":"","arguments":[867]}}
```
And after:
```
{"x":[1,0],"a":"$","b":4,"e":"15","i":0,"k":".,;(","n":11,"o":"__vsl9g7vfno"}
```
For global completions in a JS/TS file, this makes the completion response a little over 40% smaller.
* feat: support extension id in property `editor.foldingStrategy`
* work in progress
* use new setting 'editor.defaultFoldingRangeProvider' defined in workspace
* revert editorOptions changes
Co-authored-by: Martin Aeschlimann <martinae@microsoft.com>
Adds `DisposableMap` to help manage the lifecycle of maps of disposable values. This is useful for a few reasons:
- `DisposableMap` is itself disposable, so you can use it with `_register` or add it to a `DisposableStore`
- The implementation of `set` on `DisposableMap` prevents leaking values on override
- The `delete` implementation also makes sure it disposes of the deleted values
When an extension needs to read a data transfer file, we were previously using the index of the item. This is unreliable as it means we have to ensure the array of data transfer items never changes order
With this PR, i've switched us to use a unique `id` instead
* Use canonical uris when applying bulk edits
* move `reviveWorkspaceEditDto` into mainThreadBulkEdit
* make `reviveWorkspaceEditDto` require the uri ident service
* add test
fixes https://github.com/microsoft/vscode/issues/158845
* revive first, otherwise the `is` checks don't work
* fix tests
Switches simple patterns like:
```ts
if (some.thing) {
some.thing.method();
}
```
to:
```ts
some.thing?.method()
```
This is more concise and avoids having to repeat the `some.thing` part
This updates the text editor drop proposal (#142990). This change introduces `DocumentDropEdit` which removes the need for `SnippetTextEdit`. This interface may also be extended in the future with additional metadata
* Iterate on paste edit provider api
For #30066
- Pass all selections to paste providers. For #151326
- Introduce `DocumentPasteEdit` as return type. This new type uses an `insertText` that is applied to every paste location (for multicursor), plus an optional additional edit
- Add `DocumentPasteProviderMetadata`. This lets extensions tell us which types of mimetypes they are interested in, letting us avoid round trips if no extensions care about the pasted data
* Correctly batch insertText
Currently our data transfer implementation only allows a single entry of each mimeType. There can only be a single `image/gif` file for example.
However this doesn't match how the DOM apis work. If you drop multiple gifs into VS Code for example, the DataTransfer you get contains entries for each of the gifs.
This change allows us to also support DataTransfers that have multiple entries with the same mime type. Just like with the DOM, we support constructing these duplicate mime data transfers internally, but do not allow extensions to create them
As part of this change, I've also made a few clean ups:
- Add helpers for creating dataTransfer items
- Clarify when adding a data transfer item should `append` or `replace`
- Adopt some helper functions in a few more places
For #30066
This adds a new `documentPaste` api proposal that lets extensions hook into copy and paste.
This can be used to do things such as:
- Create link when pasting an image
- Bring along imports when copy and pasting code
This change attempts to clean up our internal data transfer types
- Replace `IDataTransfer` (which was just an alias for map) with a `VSDataTransfer` helper class.
This lets us add helpers and also restrict what you can do on a datatransfer
- Move `DataTransferDTO` types into `protocol`
- Move `DataTransferTypeConverter` into `typeConvert`
- Don't return internal types to ext host callers
For example, previously we leaked `IDataTransfer` out into providers / controllers. Instead we should always return an instance of `vscode.DataTransfer` to extensions
* Add drop into editor option
This change adds a new `enableDropIntoEditor` editor option that enables/disables dropping an extermal resources into an editor
Previously this option was exposed `IEditorConstructionOptions`, however this did not correctly disable drop into editor when dragging and dropping unknown types (such as dragging emoji from the MacOS emoji panel)
With this change, disabling `workbench.editor.dropIntoEditor.enabled` should fully disable the new drop into behavior
* Move drop into editor from workbench to editor
This moves the `dropIntoEditorContribution` from the workbench layer to the platform layer
As part of this change, I also add to move `extractEditorsDropData` up to `platform` so that it could be used from the `editor` layer
This change also enables drop into for the SCM message box
* Fixing monaco errors
* Revert id change
* Add experimental support for reading files in data transfer
Adds a new `DataTransfer.asFile` method which lets you get file objects from a `DataTransfer`. This is currently only hooked up for drop into editors.
A few follow ups:
- Right now the file data is also read eagerly when it is transfered to the extension host. Before shipping this we would make this happen lazily instead
- The drop into editor api does not provide a nice way to do anything with the dropped files.
We should at least support returning a `WorkspaceEdit`. However `WorkspaceEdit` only supports text files, so we would also need to add an API that lets it deal with binary files
* Make `asFile` return a value instead of a promise
`asFile().data()` already returns a promise so `asFile` doesn't also need to be async
* Trying resolving data files transfer lazily
* Cleaning up code for lazy drop
* Remove testing code
* Remove unneeded buffer serialize
* 💄
Johannes Rieken
Matt Bierner
Cristopher Claeys
Henning Dieterichs
Baptiste Augrain
Henning Dieterichs
Alex Dima