Vscode-jupyter: Open With allows using the custom editor even when it's not supported.

[rchiodo]

Use the 'Open With' menu
These options show up:

If you pick the first one on insiders it will just fail.
If you pick the second one on stable it will just fail.

We either need a way to remove these or put up a warning or switch over to the one that works when that occurs.

[joyceerhl]

Doesn't look like there's a way to control when those editor options show up in that dropdown:

• https://code.visualstudio.com/api/extension-guides/custom-editors#contribution-point
• https://code.visualstudio.com/api/extension-guides/notebook#content-provider

Would be nice if we could control the visibility of these options with when clauses too, but in the meantime I'll go with the switch over to the one that works when that occurs option, unless anyone has objections

cc @DavidKutu @IanMatthewHuff @DonJayamanne

[rchiodo]

I think I'd want to put up a warning at least? That way the user at least has some idea why the wrong UI opened.

[IanMatthewHuff]

Yeah, as long as it's not super difficult a warning would be nice. Otherwise it's just headbanging for a user.

[joyceerhl]

From the extension side, it appears we don't have any way to know when the user requests to open a preview notebook in stable (it appears to error before NotebookContentProvider.openNotebook is invoked, so we don't get a chance to handle the failure before VSCode displays an error message). I do see that when a user opens a notebook with a custom editor, an onCustomEditor activation event is fired, but I believe that's only for activation.

Given all that I'd consider this a bug on VSCode's end. They should either provide extensions with a way to control the visibility of these view options, or control the visibility of these view options themselves (e.g. preview notebook editor should clearly not be available in stable). What do y'all think?

[rchiodo]

Given all that I'd consider this a bug on VSCode's end.

We could register the editor (that's why we don't get called) and when the open editor function is called tell the user it's not supported. As long as we don't set the editor associations to 'default' then the custom or notebook editors shouldn't be called unless the user explicitly picks the 'Open With' option.

The bug here is that we have editors in the package.json but then don't call register for them.

[DonJayamanne]

We could register the editor (that's why we don't get called) and when the open editor function is called tell the user it's not

Agreed. In the content provider we can return an empty document & throw the error message in there.

As for Custom Editor, why don't we remove that, until VS Code fixes the issues we need fixed (i think currently we have some upstream issues, considering their workload, sounds like it will not get fixed).
That's one less item in the drop down list.

[rchiodo]

I believe this is already fixed

[IanMatthewHuff]

Validated. At least it's validated with a warning for both scenarios now. Wonder if we lost some history on this? I seem to recall already validating this before.