API for custom editor panes

[firelizzard18]

Issue Type: Feature Request

Update/Clarification: I am suggesting a UI API that could be used instead of the WebView API.

Looking at #12176 and #5604 as well as the conversation around the WebView API, it seems that a common thread is the lack of support for contributing editor panes from an extension. I noticed some concern that the WebView API would facilitate extensions adding UI that was completely outside of the normal VSCode UI APIs, constraints, and thus UX, as it will allow arbitrary UIs that could be entirely inconsistent with the existing VSCode UI. While I support the WebView API, as there are definitely some strong use-cases, I agree that maintaining consistency of UI/UX design across the board is important.

I think that it would be extremely valuable to have an API for building interfaces within the editor pane; an API that would work within the constraints of the existing VSCode UI and thus be consistent with it. If there were such an API, I think many (if not most) extension developers who are using or considering WebViews would instead use this API.

And as far as #12176 and #5604, I think an API for custom editor panes is a natural prerequisite. I think such and API could take VSCode from "very useful" to "essential and critical" development tool.

VS Code version: Code 1.23.0 (7c7da59, 2018-05-03T15:23:14.634Z)
OS version: Darwin x64 17.5.0

[xkisu]

+1 I'd like features like this for building a custom file editor for Vue.JS templates

[Kroc]

This would benefit extensions such as hex dump. As it stands, hex dump cannot work when you just click on a binary file (it shows the usual warning), you have to right-click the file and select "Show hexdump".

[firelizzard18]

@Kroc What you're looking for is #12176. This issue is about an API that could be used to create custom editors, instead of the current method of using WebViews.

[dschaefer]

And I really don't think this would be such a big leap from WebView. Right now, I can add a menu item to explorer to open a WebView to show the contents of a binary file, or even a text file, using a visualization that makes sense for that file. I could then add UI to allow the user to make changes to that visualization that could be saved back to the file. What's missing is the dirty bit to show the file needs saving in the tab and the ability to clear it when we save.

Now I'm probably over simplifying and we probably want to participate in editor commands available from the File and Edit menus as well. But that's the general idea.

I'm thinking of things like modeling tools, form based editors, etc. that give a great experience. Not everything a developer works with is text, or want to work with text. And by making WebViews so powerful, we're almost there. You're almost teasing us :).

[Kroc]

I can't speak of engineering complexity or difficulty, but this could also be seen as a way to more elegantly implement the current 'custom editors' in VSCode, like the Settings editor, Keyboard settings etc. You could think of them as custom editors used for those specific files. The user could also choose which 'editor' applies to which files such that they could choose in a orthogonal way if they want to use raw JSON, the half/half editor currently used, or the upcoming GUI. These could even be moved out to built-in extensions.

[dschaefer]

I'll replicate what I said on #12176 here since this one is probably more relevant to the implementation.

Digging through the code today trying to figure out how things are done. I have a webview panel that I'm using so took a look at how that got created. There's a WebviewEditorInput that doesn't implement any of the dirty/save methods of EditorInput. A naive guess would be to hook those up so that the extension would manage the content but trigger the EditorInput through the RPCProtocol.

The second question would then be how do you make it so you're webview gets created when opening the file. My initial feeling there would be to allow an extension to register an openCommand with a language. That command could then set up the webview. In the FileController.onLeftClick handler, it could check the language of the file and if it has a command, call it, and if not, call openEditor as it does now. Or maybe that happens inside openEditor. Somewhere before it tries to open a textEditor.

Undo/Redo is a bit more complicated. Looks like we'll need hooks in EditorOrNativeTextInputCommand which routes the command to the active/focused text editor. There's already a hook there to send the command to the document if it can't find the active editor. As the extension would be expected to manage the content, it would also have to have it's own undo/redo stack.

Just some thoughts. I'll play with these ideas and see how well the work out. Be great if someone from the vscode team can tell me I'm crazy or if they have a better idea :)

[dschaefer]

Did a quick check but it doesn't look like the clipboard commands from the menu are getting to the document in the webview. The keyboard ones are working fine. But that could be a separate issue.

[firelizzard18]

To clarify, I am suggesting something separate and different from the WebView API. I want a separate API that can be used to build editors. As in, something that would make VSCode's UI components accessible and allow extension developers to contribute editors that used VSCode's own UI elements.

@dschaefer

[dschaefer]

The main reason I suggest the webview approach is that it complies with their architecture of keeping extensions in their own processes to keep the main UI responsive. I'll create new bugs for my suggestions and leave this one to your original goals.

[jbrownson]

@dschaefer please post a link here if/when you open the new issue, I'd like to follow it too.

[leidegre]

Does it really make sense to push a feature like this into VS Code? I get why it would be nice to do so but thinking about the added complexity of doing so, it's going to breed a lot of extensions that probably work oh, not so-so well. Which I think would be a great disservice to the whole VS Code text-centric ecosystem. Arguably the success of VS Code is it's simplicity.

However, having a way of providing a read-only custom view of arbitrary binary files, might be reasonable for browsing purposes and I don't think it matters if the break away from the UI consistency that is VS Code, it would just be a web page displaying information. Possibly with the option to configure that such tools are edited using external editors.

[firelizzard18]

I certainly think it makes sense to have this feature in VS Code (or I wouldn't have created this issue). As I stated in the description, I think this would increase the consistency of extension UI design, as currently such UIs are built with WebViews and can be arbitrarily constructed, and thus increase the quality of those extensions.

There are already many extensions that work not-so-well. This feature wouldn't meaningfully change that situation. And the ecosystem would continue to thrive, because developers would continue to eschew the bad extensions.

[dschaefer]

I think it's a natural fit. With webviews, we're already have the most complicated part. Just need to hook it up so that the framework opens up the webview instead of the text editor and hooks up a few editor actions.

And going through the code, not sure I agree it's simple. There's a pretty powerful but complex framework underneath that simple UI. But that's what makes vscode so good.

And at the end of the day, if an extension does a bad job of it, it gets bad reviews and can always be uninstalled. Those who do a good job will make sure they don't disturb the great text editor experience and we'll have the right IDE for the next 20 years.

[mjbvz]

As I understand it, the original request here was for a set of user interface components that extensions could use to build custom UI. I feel this is out of scope. We do not want to get into the business of being a general purpose user interface library.

Instead, we push extensions to provide data that VS Code can surface to users in consistent and performant manner. This obviously limits what extensions can do but we feel these limitations are key to maintaining the overall quality and of VS Code

A few related issues:

• Fully customizable editors (using webviews) Allow to open a custom file viewer window without opening the default one #12176
• Custom sections of user interface within editors (also using webviews): Code inset feature #66418

Closing this feature request as out of scope