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

Custom webview editor API #77131

Open
mjbvz opened this issue Jul 10, 2019 · 65 comments
Open

Custom webview editor API #77131

mjbvz opened this issue Jul 10, 2019 · 65 comments

Comments

@mjbvz
Copy link
Contributor

@mjbvz mjbvz commented Jul 10, 2019

Updated: December 19, 2019

Current status of API

Overview

The custom editor API aims to allow extensions to create fully customizable read/write editors that are used in place of VS Code's standard text editor for specific resources. These editors will be based on webviews. We will support editors for both binary and text resources

A XAML custom editor, for example, could show a WYSIWYG style editor for your .xaml files. Our end goal is to give extensions the most flexibility possible while keeping VS Code fast, lean, and consistent.

Non-goals

Many features that are potentially related to custom editors are out of scope of this current proposal, including:

  • Specifying how resources are persisted and how resources are synchronized with webviews
  • Specifying what an edit is
  • Customization of VS Code's text editor using html / css
  • Embedding of VS Code's text editor in webviews
  • UI related to custom editors (beyond switching view types)

These all would fall under separate feature requests. Many also be a better fit for an external helper library instead of VS Code core

Tracking progress

This issue thread captures the evolution of the webview editor proposal. That means that many comments may now be out of date. Some of these have been minimized, others have not.

For the most up to date info, see:

TODO

Big remaining questions related to custom editors include:

  • Hot exit support for custom editors
  • Implement saveAs properly
  • Should the api include a rename event?
  • Bug fixing and UX polishing
@mjbvz mjbvz added this to the July 2019 milestone Jul 10, 2019
@kieferrm kieferrm mentioned this issue Jul 10, 2019
22 of 29 tasks complete
@mjbvz

This comment was marked as outdated.

Copy link
Contributor Author

@mjbvz mjbvz commented Jul 11, 2019

Two main parts of this that I see:

  • Custom views for resources (interactive but not editable)

    A good example would be an image or 3d model viewer. To test out this api, we could even look into moving our builtin image preview into an extension

    • Basic case of just opening a custom view for a resource
    • Switching the custom view for a resource (if multiple potential custom views are registered for it)
    • Configuring the default custom view for a resource
    • Making sure that extensions are lazily activated for all these cases
  • Custom editors for resources (hooking the custom views up to VS Code's text editor lifecycle)

    These would be custom views that can be edited and saved like normal VS Code text editors

    • Handling saves?
    • How much should VS Code control and how much should we leave up to extension? Copy/paste for example. Is that something VS Code should specifically delegate to the custom editor or let each extension implement?
@mjbvz

This comment was marked as outdated.

Copy link
Contributor Author

@mjbvz mjbvz commented Jul 11, 2019

Some quick sketches

Api

export enum WebviewEditorState {
	Default = 1,
	Dirty = 2,
}

export interface WebviewEditor extends WebviewPanel {
	state: WebviewEditorState;

	readonly onWillSave: Event<{ waitUntil: (thenable: Thenable<any>) => void }>
}

export interface WebviewEditorProvider {
	/**
	* Fills out a `WebviewEditor` for a given resource.
	*
	* The provider should take ownership of passed in `editor`.
	*/
	resolveWebviewEditor(
		resource: Uri,
		editor: WebviewEditor
	): Thenable<void>;
}

export function registerWebviewEditorProvider(
	viewType: string,
	provider: WebviewEditorProvider,
): void;

Contributions

{
	"contributes": {
		"webviewEditors": [
			{
				"viewType": "hexViewerExtension.hexEditor",
                                "displayName": "Hex Editor",
				"languages": [
					"hexdump"
				]
			}
		]
	}
}

UX

User clicks on a hexdump file for the first time

  • If no custom view for a hexdump file is registered.

    • Fallback to VS Code's existing behavior
  • If only a single extension is registered for a hexdump file

    • Fire an activation event
    • Extension registers a custom view provider by calling registerWebviewEditorProvider for hexViewerExtension.hexEditor
    • VS Code invokes this provider with a WebviewEditor that the extension fills out
  • If multiple extensions are registered for a hexdump file

    • Show a quick pick UI asking the user to select which custom view they would like. (and potentially persist this choice)
    • After a selection is made, go through flow as if we have a single registered editor

User has a custom view open and wants to change to a different view

  • Show the quick pick for selecting which editor to use. Include vscode's default view
  • After the user makes a selection and changes the editor they wish to use, destory the old view and recreate a new view in its place
@jrieken

This comment was marked as outdated.

Copy link
Member

@jrieken jrieken commented Jul 11, 2019

I like, I think this goes into the right direction. Other ideas/thoughts when looking at this

  • Is language the right abstraction? hexdump or png is not really a language but types of files and languages might just be a subset of that. So, instead or in addition to language I would favour something like pattern
  • Allow to opt-in to saving, e.g hexdump might be reading only?
  • Many web views work with a master text editor, like markdown or jupiter notebooks, and I think it would make to design for that from the beginning, e.g have a (static) flag to signal that this is a master-detail case (related discussion #22068)
@TomMarius

This comment was marked as outdated.

Copy link

@TomMarius TomMarius commented Jul 15, 2019

Is language the right abstraction? hexdump or png is not really a language but types of files and languages might just be a subset of that. So, instead or in addition to language I would favour something like pattern

Very good point. Think of files like WASM that can be represented and modified as text in multiple formats (parens form, linear form) as well as block diagram as well as hexadecimal...

Or SVG, which could be viewed inside an image editor as well as XML editor.

I'm very hyped about this.

@sijakret

This comment has been minimized.

Copy link

@sijakret sijakret commented Jul 16, 2019

Is it possible i read in the docs for extension developers (about a year ago) that functionality like this was deliberately not supported for performance and stability reasons?

Not that i'm not hyped as well.. ;)

@jrieken jrieken modified the milestones: July 2019, August 2019 Jul 29, 2019
@kieferrm kieferrm mentioned this issue Aug 10, 2019
25 of 37 tasks complete
mjbvz added a commit that referenced this issue Aug 16, 2019
For #77131

Adds a prototype of custom editors contributed by extensions
mjbvz added a commit that referenced this issue Aug 16, 2019
For #77131

Adds a prototype of custom editors contributed by extensions. This change does the following:

- Introduces a new contribution point for the declarative parts of a custom editor
- Adds API for registering a webview editor provider. This lets VS Code decided when to create a webview editor
- Adds an `openWith` command that lets you select which editor to use to open a resource from the file explorer
- Adds a setting that lets you say that you always want to use a custom editor for a given file extension
- Hooks up auto opening of a custom editor when opening a file from quick open or explorer
- Adds a new extension that contributes a custom image preview for png and jpg files

Still needs a lot of UX work and testing. We are also going to explore a more generic "open handler" based approach for supporting custom editors

Revert
@mjbvz

This comment was marked as outdated.

Copy link
Contributor Author

@mjbvz mjbvz commented Aug 17, 2019

An API proposal and a draft implementation is in #77789. That one ties custom editors to webviews specifically.


An alternative approach that @jrieken and @bpasero brought up is more generic "open handler" extension point. Here's a quick draft of what this could look like:

Contributions

{
	"contributes": {
		"openHandler": [
			{
				"id": "imageView.imageViewer",
                                "displayName": "Image Viewer",
				"extensions": [
					"png",
					"jpg"
				]
			}
		]
	}
}

API

/* ignoring all the editable stuff about webview editors for the moment */

export interface WebviewEditor extends WebviewPanel { }

export function createWebviewEditor(resoruce: Uri, viewType: string, showOptions: ViewColumn | { viewColumn: ViewColumn, preserveFocus?: boolean }, options?: WebviewPanelOptions & WebviewOptions): WebviewEditor;

export function registerOpenHandler(
	id: string,
	handler: (resource: Uri, viewColumn: ViewColumn) => void,
): void;

Usage

export function activate() {
  vscode.window.registerOpenHandler('imageView.imageViewer', (resource: vscode.Uri, viewColumn: ViewColumn) => {
      vscode.window.createWebviewEditor(resource, 'imageView.imageView', viewColumn);
      ...
  });
}

Advantages over first API proposal

  • Very generic. Enables some potentially interesting uses like opening a external editor when clicking on a resource for example
  • Could be built on by future apis since it is not webview specific

Disadvantages

  • Maybe too generic? It lets extensions potentially do all sorts of non-standard things
  • Could this let extensions slow down the VS Code UX?
  • It would likely require duplicating more API around webviews (we'd need serializers for example)
  • Should extensions be able to arbitrarily invoke createWebviewEditor? Just as one example of why we may not want to allow this, we likey only want to allow one editor for a given resource per view column

/cc @Tyriar @kieferrm Since I know you were also interested in the discussion around the "open handler" proposal

@Tyriar

This comment was marked as outdated.

Copy link
Member

@Tyriar Tyriar commented Aug 20, 2019

Some thoughts:

  • The open handler seems too flexible to me. Since it doesn't return any value and it could literally do anything, the extension would need to do a bunch of management around editors that VS Code can do for no cost using the other approach. For example, clicking on a file with the same editor twice, the extension would need to know to focus the existing editor.
  • I think undo and redo should definitely be considered from the beginning in order to make more useful non-read only editors.
@mjbvz

This comment was marked as outdated.

Copy link
Contributor Author

@mjbvz mjbvz commented Aug 20, 2019

After talking over the "open handler" proposal with @Tyriar and thinking about it more, I agree that it is likely too open ended in its current form. Does anyone has any specific use cases for the "open handler" proposal that could not be addressed by the previous custom editor proposed API or by existing VS Code apis?


As for commands such as undo/redo in webview, a couple of options:

  • Add events for very common commands such as save, undo, and redo:

    readonly onWillSave: Event<{ waitUntil: (thenable: Thenable<any>) => void }>
    readonly onWillUndo: Event<{ waitUntil: (thenable: Thenable<any>) => void }>
    readonly onWillRedo: Event<{ waitUntil: (thenable: Thenable<any>) => void }>
    ....
  • Add a generic way to listen for commands:

    onWillExecuteCommand(command: 'workbench.action.files.save' | 'undo' | 'redo' | ..., handler: (e) => Thenable<any>>

Both solutions would require that extensions explicitly state which commands they are interested in. This lets us avoid sending all commands to extensions, and would also let us enable/disable the relevant buttons in the menubar. (We may still want to consider save a special case since it will be very common and may have special requirements)

@jrieken

This comment has been minimized.

Copy link
Member

@jrieken jrieken commented Aug 21, 2019

Does anyone has any specific use cases for the "open handler" proposal that could not be addressed by the previous custom editor proposed API

I think a use-case would be files that open as text but need some prior processing. E.g clicking a foo.class-file shouldn't open a web view editor but, after a decompile-step, should open a foo.generated.java-file. However, we can treat that as a different problem and think about it as a default text content provider so certain file-types.

Let's continue with the existing proposal.

I think undo and redo should definitely be considered from the beginning in order to make more useful non-read only editors.

@Tyriar Can you explain why? We have added save-logic because editors render the dirty state (in their titles) but undo/redo isn't part of the editor UX. I agree that undo/redo is important but to me it's just commands that an extension should register.

@bpasero

This comment has been minimized.

Copy link
Member

@bpasero bpasero commented Aug 21, 2019

Does anyone has any specific use cases for the "open handler" proposal that could not be addressed by the previous custom editor proposed API or by existing VS Code apis?

So are we saying that https://marketplace.visualstudio.com/items?itemName=slevesque.vscode-hexdump needs to rewrite the extension so that the standalone editor is embedded into a webview? So they would have to ship the standalone editor as part of their extension? This scenario is quite popular (see #2582, has even more upvotes than #12176).

Maybe I misunderstood and we are still thinking of supporting text editors to open but with the previous API.

@jrieken

This comment has been minimized.

Copy link
Member

@jrieken jrieken commented Aug 21, 2019

Maybe I misunderstood and we are still thinking of supporting text editors to open but with the previous API.

Yeah, I think that's still a valid scenario, e.g. the webview editor should have an option to let the workbench know that it wants to show to the side of a text editor. For hexdump but also for markdown

@bpasero

This comment has been minimized.

Copy link
Member

@bpasero bpasero commented Aug 21, 2019

To be clear, here is what I expect:

  • I open the explorer
  • I click on a file that is binary
  • hexdump extension opens with a text editor with custom content

I agree that I would not put the burden of finding out if the editor is already opened onto the extension but on us.

@Tyriar

This comment has been minimized.

Copy link
Member

@Tyriar Tyriar commented Aug 21, 2019

Can you explain why? We have added save-logic because editors render the dirty state (in their titles) but undo/redo isn't part of the editor UX. I agree that undo/redo is important but to me it's just commands that an extension should register.

@bpasero I don't mind so much on how this is done, but if the user has a custom keybindings for the regular undo/redo commands it should work in the custom editor too.

mjbvz added a commit that referenced this issue Aug 22, 2019
For #77131

Adds a prototype of custom editors contributed by extensions. This change does the following:

- Introduces a new contribution point for the declarative parts of a custom editor
- Adds API for registering a webview editor provider. This lets VS Code decided when to create a webview editor
- Adds an `openWith` command that lets you select which editor to use to open a resource from the file explorer
- Adds a setting that lets you say that you always want to use a custom editor for a given file extension
- Hooks up auto opening of a custom editor when opening a file from quick open or explorer
- Adds a new extension that contributes a custom image preview for png and jpg files

Still needs a lot of UX work and testing. We are also going to explore a more generic "open handler" based approach for supporting custom editors

Revert
mjbvz added a commit that referenced this issue Aug 24, 2019
For #77131

Adds a prototype of custom editors contributed by extensions. This change does the following:

- Introduces a new contribution point for the declarative parts of a custom editor
- Adds API for registering a webview editor provider. This lets VS Code decided when to create a webview editor
- Adds an `openWith` command that lets you select which editor to use to open a resource from the file explorer
- Adds a setting that lets you say that you always want to use a custom editor for a given file extension
- Hooks up auto opening of a custom editor when opening a file from quick open or explorer
- Adds a new extension that contributes a custom image preview for png and jpg files

Still needs a lot of UX work and testing. We are also going to explore a more generic "open handler" based approach for supporting custom editors

Revert
@KevinWuWon

This comment has been minimized.

Copy link

@KevinWuWon KevinWuWon commented Dec 3, 2019

@mjbvz The dirty bit is important not just for the visual indication that there are changes, but also for controlling whether the Save/Don't Save/Cancel dialog appears when the user closes the tab. Also for the "Close Unsaved" command and the like.

Without it, users are prone to losing unsaved work, which is bad.

@RandomFractals

This comment has been minimized.

Copy link

@RandomFractals RandomFractals commented Dec 4, 2019

ok. Let me throw my bits in the mix on this:

First of all this is a really great idea to simplify scaffolding of webviews and custom editors for different file types.

Question: if a custom web editor requires separate config for webview settings, connection strings, etc. would you expect it to manage that via exposed state/edit API?

I'd love to port Data Preview 🈸 to this API when it's fully baked, but I think we could use additional 'config' files mapping for the resource and such web editor. State/edit API is good enough for saves and restores, but falls short for custom editor config settings per file view. Could be a good next step to try and standardize that as part of this effort too.

See https://github.com/RandomFractals/vscode-data-preview/tree/master/data/json for some examples of how I handle it for json data files preview. Could be a good test bed too ...

In my case, I can see data preview config changes handled with undo/redo stack and save.

Do you have read/update/save and undo/redo fully implemented yet for me to try it?

My expectations are vscode would handle file changes and stream data reads of local and remote text and binary formats, per line for text and per 1K or so for binary data. see https://nodejs.org/api/readline.html for example. Any plans of adding that to worksspace.fs api any time soon? My simple data files processing use case for that scenario, whenever that fs api is available: RandomFractals/vscode-data-preview#167 Till then I think I'll stick with nodejs fs api.

Also, I have not implemented Undo/Redo yet, but if you want a practical use case that's beyond the cat drawing apps :), see RandomFractals/vscode-data-preview#25

@mjbvz you might find my data preview Save As use cases interesting to. Would be nice if a web editor could register save as file types, and vscode then exposed that UI to the developer via a standard UX. For most graphics views those webviews typically require custom save as png commands and UI. You can also view Vega Viewer for that scenario: https://github.com/RandomFractals/vscode-vega-viewer

@mjbvz

This comment has been minimized.

Copy link
Contributor Author

@mjbvz mjbvz commented Dec 4, 2019

@RandomFractals

  1. Not sure what you mean by separate config? Are you talking about VS Code settings? Can you share your use case

  2. Yes undo and save are ready for testing in insiders.

  3. There is no streaming built in. The current API leaves file watching and saving entirely up to extensions, so you are free to implement file syncing / save however you want including using streaming. Please file separate feature requests if the vscode fs apis don't offer what you need

  4. Creating more advanced save as flows is outside the scope of this api. You are probably better implementing a custom Save as png command for your custom editor if you need to get user input beyond the file name while saving

@mjbvz

This comment has been minimized.

Copy link
Contributor Author

@mjbvz mjbvz commented Dec 4, 2019

@KevinWuWon I think the concept of an open stack element for undo/redo may be interesting. But could you implement that using the current API by maintaining your own edit data?

If the user types hello for example:

  1. h

    • Some editing has started so push { id: 1 } onto the VS Code undo stack
      -Also, in your extension, have a map from edit id to actual edit data: { 1: [{ insert: 'h' }]}
  2. e

    • Do nothing with vs code stack
    • Update your extension's internal edit data with the new data: { 1: [{ insert: 'h' }, { insert: 'e' }]}
  3. Continue this for letters through o.

  4. At this point, your extension decide to commit the edit (create an undo stop). When this happens, on the next text change, you push a new edit with a new id onto VS Code's stack

  5. However, if an undo had occurred before you committed the edit, VS Code would tell you to undo { id: 1}. You lookup the real data for the id and then undo that

@KevinWuWon

This comment has been minimized.

Copy link

@KevinWuWon KevinWuWon commented Dec 4, 2019

Nice idea, I think that might actually work. Now I just need Monaco to report when undo stops are created.

@RandomFractals

This comment has been minimized.

Copy link

@RandomFractals RandomFractals commented Dec 4, 2019

@mjbvz so, based on your feedback to my data read/write and save as use cases, this web editor api in its v1 incarnation will be good only for very basic read/save/update files handling with alternative webviews.

I'll open separate tickets for the scenarios I brought up. If you try Data Preview extension, you should have a fairly clear picture of what my requirements are to migrate to this api and I don't think they are advanced in any way, but perhaps could be good for your rev. 2 of this web editor api.

@mjbvz

This comment has been minimized.

Copy link
Contributor Author

@mjbvz mjbvz commented Dec 13, 2019

This iteration, we're looking into making the view / model separation more clear for webview editors. The proposed fixes and background for it are fairly verbose, so I've temporarily forked off the discussion for it to #86802. Please post feedback/questions there if you are interested in editable webview editors

Once we settle on what we are going to attempt in #86802, I'll post the results back to this issue and close #86802

@RandomFractals

This comment has been minimized.

Copy link

@RandomFractals RandomFractals commented Dec 13, 2019

@mjbvz it's so weird how you always have 10 layers of misdirection in your github issues spinoffs & PR's reassignments. a bit hard to follow your flow, but ok!

@mjbvz

This comment has been minimized.

Copy link
Contributor Author

@mjbvz mjbvz commented Dec 20, 2019

Based on the outcome of #86802, we've updated the proposed api to the following:

/**
 * Defines the editing functionality of a webview editor. This allows the webview editor to hook into standard
 * editor events such as `undo` or `save`.
 *
 * @param EditType Type of edits. Edit objects must be json serializable.
 */
interface WebviewCustomEditorEditingDelegate<EditType> {
	/**
	 * Save a resource.
	 *
	 * @param resource Resource being saved.
	 *
	 * @return Thenable signaling that the save has completed.
	 */
	save(resource: Uri): Thenable<void>;

	/**
	 * Save an existing resource at a new path.
	 *
	 * @param resource Resource being saved.
	 * @param targetResource Location to save to.
	 *
	 * @return Thenable signaling that the save has completed.
	 */
	saveAs(resource: Uri, targetResource: Uri): Thenable<void>;

	/**
	 * Event triggered by extensions to signal to VS Code that an edit has occurred.
	 */
	readonly onEdit: Event<{ readonly resource: Uri, readonly edit: EditType }>;

	/**
	 * Apply a set of edits.
	 *
	 * Note that is not invoked when `onEdit` is called as `onEdit` implies also updating the view to reflect the edit.
	 *
	 * @param resource Resource being edited.
	 * @param edit Array of edits. Sorted from oldest to most recent.
	 *
	 * @return Thenable signaling that the change has completed.
	 */
	applyEdits(resource: Uri, edits: readonly EditType[]): Thenable<void>;

	/**
	 * Undo a set of edits.
	 *
	 * This is triggered when a user undoes an edit or when revert is called on a file.
	 *
	 * @param resource Resource being edited.
	 * @param edit Array of edits. Sorted from most recent to oldest.
	 *
	 * @return Thenable signaling that the change has completed.
	 */
	undoEdits(resource: Uri, edits: readonly EditType[]): Thenable<void>;
}

export interface WebviewCustomEditorProvider {
	/**
	 * Resolve a webview editor for a given resource.
	 *
	 * To resolve a webview editor, a provider must fill in its initial html content and hook up all
	 * the event listeners it is interested it. The provider should also take ownership of the passed in `WebviewPanel`.
	 *
	 * @param resource Resource being resolved.
	 * @param webview Webview being resolved. The provider should take ownership of this webview.
	 *
	 * @return Thenable indicating that the webview editor has been resolved.
	 */
	resolveWebviewEditor(
		resource: Uri,
		webview: WebviewPanel,
	): Thenable<void>;

	/**
	 * Controls the editing functionality of a webview editor. This allows the webview editor to hook into standard
	 * editor events such as `undo` or `save`.
	 *
	 * WebviewEditors that do not have `editingCapability` are considered to be readonly. Users can still interact
	 * with readonly editors, but these editors will not integrate with VS Code's standard editor functionality.
	 */
	readonly editingDelegate?: WebviewCustomEditorEditingDelegate<unknown>;
}

namespace window {
	/**
	 * Register a new provider for webview editors of a given type.
	 *
	 * @param viewType  Type of the webview editor provider.
	 * @param provider Resolves webview editors.
	 * @param options Content settings for a webview panels the provider is given.
	 *
	 * @return Disposable that unregisters the `WebviewCustomEditorProvider`.
	 */
	export function registerWebviewCustomEditorProvider(
		viewType: string,
		provider: WebviewCustomEditorProvider,
		options?: WebviewPanelOptions,
	): Disposable;
}

The main differences over the proposed API in VS Code 1.41:

  • The editingDelegate (previously called the editingCapabilities) is now specified on the provider instead of being returned by resolveWebviewEditor

  • This means is now a single editing delegate for all custom editors of a given type. With this setup, actions such as save should only be fired once per resource (not once per editor)

  • To support having a single delegate object, all delegate methods now take a resource that specifies what resource we are talking about

This api is now in vscode.proposed.d.ts and the example custom editors have been updated to use it

We are still looking into how best support hotexit and how many hooks we should expose to extensions around this

@mjbvz mjbvz changed the title Custom editor view exploration Custom webview editor API Dec 20, 2019
@kieferrm kieferrm mentioned this issue Dec 20, 2019
6 of 53 tasks complete
@DonJayamanne

This comment has been minimized.

Copy link
Contributor

@DonJayamanne DonJayamanne commented Dec 21, 2019

@mjbvz Is there a way for the extension to tell VS Code to NOT load the custom editor.
I'm thinking of scenarios such as the git diff view. When user opens a file in source control history view, then we need to display the differences. At this point, we'd prefer for VS Code to display its own text base diff viewer.

Further to this, sometimes I've found the need to view the raw file content instead of using the custom editor. Out of curiousity, is there a provision for such a scenario. E.g. displaying an icon on the top right, that allows users to open the raw viewer. Similar to displaying the icon to open settings.json file instead of the settings viewer.

@RandomFractals

This comment has been minimized.

Copy link

@RandomFractals RandomFractals commented Jan 8, 2020

@mjbvz do you have an ETA on when this api will be released as part of vscode for general public?

I've seen February release mention in some other related issue thread.

Does it mean we'll see it as part of built-in vscode api only in March?

Any heads up on your timeline for the GA relase of this api would be much appreciated to help 3rd party extension devs plan accordingly.

Thanks!

@rchiodo

This comment has been minimized.

Copy link

@rchiodo rchiodo commented Jan 8, 2020

@mjbvz had a question about 'blank' files. Right now we allow a user to create a 'blank' notebook. For a normal text document, this would be handled by openTextDocument with options specifying untitled.

Would this work by just passing the correct 'language' to openTextDocument?

@RandomFractals

This comment has been minimized.

Copy link

@RandomFractals RandomFractals commented Jan 8, 2020

@mjbvz & @rchiodo I have the same scenario in my extensions like create new Vega chart || kepler.gl map.

How do we handle that with this api?

I mean I can provide Untitled templates, but what's the vscode provided tooling for that new graph || map with this custom webview editor api ;) ...

@mjbvz

This comment has been minimized.

Copy link
Contributor Author

@mjbvz mjbvz commented Jan 10, 2020

@rchiodo You can open a custom editor for an untitled file using a uri with an untitled: scheme. For a custom editor for *.abc files for example, you would open a file with the uri untitled:file.abc.

Note that you need to open this file using the vscode.open command and not openTextDocument since custom editors are not backed by text documents

mjbvz added a commit that referenced this issue Jan 10, 2020
Fixes #88426

Add an api command that allows extensions to open/reopen a file with a specific we custom editor. Use this to allow re-opening a failed to load image as text/binary

For #77131
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.