Why TabKindCustom and TabKindNotebook

[bpasero]

Testing #145585

I am not sure if we start to bleed our internal editor system as an extension API now. It is true that internally we mainly have 3 sources of editors:

• text
• custom (webview based)
• notebooks

But as a user or extension developer, is that really important? I wonder if custom and notebook should merge into one specific kind that provides more details about the editor kind via the viewType property?

Besides, isn't a notebook editor a "custom" editor for a text file?

[bpasero]

Obviously if you continue on this thought you could argue that even TabKindText could merge into the others and in the end you only have this:

class TabKind {
   readonly uri: Uri;
   readonly viewType: string;
}

class TabKindDiff {
   readonly original: Uri;
   readonly modified: Uri;
   readonly viewType: string;
}

[lramos15]

I had a similar suggestion but the idea here is in the future to possibly expose the notebook object through the tab for example if we wanted to. Also @jrieken didn't really like the idea of exposing default for the text values as he felt that was an internal construct. This way you can do instanceof checks and have a concrete understanding of what is being represented. It is a bit annoying when you just care about resource though as you have to do something like this

vscode/src/vs/workbench/api/common/extHostDebugService.ts

Lines 959 to 963 in 1f244e7

	if (activeTab.input instanceof TextDiffTabInput || activeTab.input instanceof NotebookEditorDiffTabInput) {
	return activeTab.input.modified;
	} else if (activeTab.input instanceof TextTabInput || activeTab.input instanceof NotebookEditorTabInput || activeTab.input instanceof CustomEditorTabInput) {
	return activeTab.input.uri;
	}

[jrieken]

I am not sure if we start to bleed our internal editor system as an extension API now. It is true that internally we mainly have 3 sources of editors:

I don't think so: we already have (or have proposed) vscode.TextEditor, vscode.NotebookEditor, and vscode.WebviewPanel. We are not giving away more than we already did/do.

Assuming we merge notebook and custom editors into one TabKindCustom-instance: how would you tell them apart? There is no global viewType registry that extensions can read from. It will, actually did in previous versions of this proposals, lead to another property that signals the "kind" of tab, e.g. viewType: string and tabKind: TabKind (with TabKind being an enum with more or less Text, Notebook, Custom etc). I believe there is a lot more clarity in the use of classes/constructors for these different cases: you can use instanceof-checks, you know exactly what you are dealing with, and we have ability to further specialise them in the future. I think that much better than strings that need to compared well-known and lesser known values.

Thinking about the name for TabKindCustom: Maybe it is a bit too generic. We call the concept custom editors but we could also call the tab kind TabKindWebview: that could then cover custom editors as well as none-editor web view panels (like MD preview)

[lramos15]

Thinking about the name for TabKindCustom: Maybe it is a bit too generic. We call the concept custom editors but we could also call the tab kind TabKindWebview: that could then cover custom editors as well as none-editor web view panels (like MD preview)

Webviews cannot be opened via vscode.open and I'm not sure there is much information resource wise for a webview tab

[bpasero]

Hm, now that I took a look again into the API for extension, my statement was not right, we do indeed distinguish:

• CustomDocument
• NotebookDocument
• TextDocument

In that case it is probably fine to keep it the way it is and extension devs can understand the origin of each editor.

Since terminals are also quite prominent in the API maybe we should prepare to have a tab kind for that one as well.

[jrieken]

Since terminals are also quite prominent in the API maybe we should prepare to have a tab kind for that one as well.

💯

[bpasero]

I am fine closing this issue, I have reported individual issues for introducing more kinds, but maybe we just wait with introducing the kinds until an extension author has asked for it?

• Have a TabKind for terminals #145895
• Have a TabKind for split in editor group #145688
• Have a TabKindCustomDiff #145743