For #77131
Going back the the delegate based model for a few reasons:
- It gives us a better approach to add additional API hooks in the future (such as for rename)
- In practive, the capabilities were almost always the same as the `userData` on the document. It is rather confusing to have both `userData` and the capabilities 'on' the document
* Use the UndoRedoService for CustomEditors
For #90110
Changes custom editors (the ones not based on text) to use the UndoRedoService. This involved:
- Moving edit lifecycle back into the main process again (this is actually the bulk of the changes)
- Removing the `undo`/`redo` methods on `CustomEditorModel`
- Using the undoRedoService to trigger undo/redo
Fixes#22353
StatusBarItem is one of the few places in our API where we only allow extensions to give us a command as a `string` instead of as `Command` object. This change updates the API to also allow passing in a `vscode.Command` (which also allows arguments!)
UI:
Adds Refresh icon to view title
Adds "Load more" entry at the end of the list for paging
API:
Restructures api around cursors
Renames TimelineCursor to generic TimelineOptions for more flexibility
Adds paging object to Timeline for clearer paging usage
Changes cursors to be strings, and explicit before and after cursors
Allows limit to take a cursor, so we can reload current data set
Clarifies id and fallback to timestamp
Adds reset flag to TimelineChangeEvent for providers to reset caching
Git provider:
Orders and returns commit date as the timestamp
Supports limit of a cursor (using rev-list --count)
Stops returning working/index changes when paging
Forcably resets cached data when changes are detected (naive for now)
For #77131
**Motivation**
While our existing webview editor API proposal more or less works, building an editable webview editor is fairly tricky using it! This is especially true for simple text based editors.
It'd also be nice if we could get bi-directional live editing for text files. For example, if I open the same file in a webview editor and in VS Code's normal editor, edits on either side should be reflected in the other. While this can sort of be implemented using the existing API, it has some big limitations
**Overview of changes**
To address these problems, we've decided have two types of webview editors:
- Text based webview editors. These editors used a `TextDocument` as their data model, which considerably simplifies implementing an editable webview. In almost all cases, this should be what you use for text files
- Complex webview editors. This is basically the existing proposed API. This gives extension hooks into all the VS Code events, such as `save`, `undo`, and so on. These should be used for binary files or in very complex text editor cases.
Both editor types now have an explicit model layer based on documents. Text editor use `TextDocument` for this, while custom editors use `WebviewEditorCustomDocument`. This replaces the delegate based approach previously used.
Adds contributable commands to timeline items
Adds right-aligned timestamp to timeline items
Adds Open Changes to Git timeline items
Adds Copy Commit ID to Git timeline items
Adds Copy Commit Message to Git timeline items
Cleans up API and removes some unused features (e.g. paging)
Adds date formatting
Adds loading progress and message
Removes lots of console.logs 😁
Adds titles to diffs
Adds a backup method to the custom editor API proposal. This method allows custom editors to hook in to VS Code's hot exit behavior
If `backup` is not implemented, VS Code will assume that the custom editor cannot be hot exited.
When `backup` is implemented, VS Code will invoke the method after every edit (this is debounced). At this point, this extension should back up the current resource. The result is a promise indicating if the backup was successful or not
VS Code will only hot exit if all backups were successful.
For #88719
With this change, instead of passing custom editor edit json back and forth with the extension host, we keep the original edit objects on the extension host. This means that we can pass extensions back the exact same edit object they first hand to us. It also means that edits no longer need to be json serializable.
- extract a separate DocumentRangeSemanticTokensProvider that deals with a document range
- extract a separate provideDocumentSemanticTokensEdits that deals with updating via SemanticTokensEdits a previous result
