Views: Support contributable welcome view content

[joaomoreno]

Problem

The need to have meaningful and actionable content rendered on empty views has been arising across the workbench:

• SCM: SCM: Viewlet should improve "no repositories" messaging #61491
• Debug: Make run and debug welcome view extensible #85548
• Custom Views: Remote Containers: Guide users to create the first container when non exists vscode-remote-release#1349

Proposal

Let's enable the following in the core:

1. Add an overridable isEmpty(): boolean method to ViewPane which would let view panes dictate when they are empty, as well as onDidChangeEmpty event
2. Create a core contribution point for empty view content, supporting very simple Markdown (links only)
3. Enhance the simple Markdown to be able to detect isolated command links and render them as buttons
4. Render all empty view contributions in a ViewPane when isEmpty() === true

We can then update our API by exposing an extension contribution point for the same core contribution point created above. Here's a couple of proposals:

contributes.documentation.VIEWID

"contributes": {
  "documentation": {
    "VIEWID": [{
       "label": "MARKDOWN",
       "when": "CONDITION"
    }]
  }
}

Alternatives for documentation: viewhelp, emptyview.

Alternatives for label: text, markdown, description.

contributes.documentation.view

"contributes": {
  "documentation": {
    "view": [{
       "label": "MARKDOWN",
       "when": "VIEWID && CONDITION"
    }]
  }
}

---

cc @sbatten for views
cc @isidorn for debug
cc @sandy081, @alexr00 for custom views
cc @bowdenk7 for scm
cc @jrieken for input on API conventions

[isidorn]

Looks good to me.

I prefer the contributes.documentation.VIEWID. That has the benefits of being more clear what it targets, looks more like the menu syntax and makes it easier for extensions to write when clauses.

I am personally not a big fan of the documentation name, however since we already use it in other places I think it makes sense to use it here also.

label is usually just a ux label, this feels to me as bit more. So I would prefer content or markdown.

Also note that debug would render something before this contributed section and something after this contributed section if possible. So the view should have the start, middle and end. With the middle being contributable.

fyi @weinand

[jrieken]

Add an overridable isEmpty(): boolean method to ViewPane which would let view panes dictate when they are empty

I guess we also need an event for when that's changing...

[jrieken]

Also adding @mjbvz for the doc contribution point

[mjbvz]

Could we put this on views contribution itself? Something like:

{
  "contributes": {
    "views": {
      "explorer": [
        {
          "id": "nodeDependencies",
          "name": "Node Dependencies",
          "when": "workspaceHasPackageJSON",
          "emptyContent": [{
            "markdown": "My empty message",
            "when": "CONDITION"
          }]
        }
      ]
    }
  }
}

If we prefer the documentation contribution point, I prefer the contributes.documentation.view approach as it lets us control the top level of the documentation namespace.

[jrieken]

One goal is that another extension can contribute getting-started text, e.g. a GH extension can contribute to the SCM view, etc. Not sure how that would look with this integrated approach

[isidorn]

Also it does not make a lot of sense for debug. Since all our extensions are not contributing views, and all of them want to contribute to our start view.

[joaomoreno]

It turns out using markdown for this isn't feasible, since the library we currently use doesn't allow to prevent certain features (headers, tables, etc), not even using the renderer API. Since all we want are actually links, another option is to extract the work @bpasero did for notifications into something reusable.

[mjbvz]

@joaomoreno We use insane to sanitize rendered markdown

vscode/src/vs/base/browser/markdownRenderer.ts

Line 189 in 82ed3d4

element.innerHTML = insane(renderedMarkdown, {

Could you configure it to only allow a very specific set of tags (try the allowedTags attribute)? Not sure if this would still be confusing for extension authors

[joaomoreno]

We would only want to support links in this feature. No headers, no images, no styling, no lists, no tables. So, we'd need a markdown feature set filter.