ResourceLabelFormatter for custom TextDocumentContentProvider's scheme ignored after first call to showTextDocument()

[kahlkevin]

Type: Bug

1. Merge this into the cowsay example's package.json (in vscode-extension-samples/virtual-document-sample):

   {
   "contributes": {
   "resourceLabelFormatters": [
     {
       "scheme": "cowsay",
       "formatting": {
           "label": "ZZ${path}ZZ"
       }
     }
   ]
   }
   }

2. Run the sample, activate the cowsay command, and enter "fubar".
3. The new editor is correctly titled ZZfubarZZ. Now click the custom action cowsay (↹) button in the editor toolbar.
4. A second editor is opened, correctly titled ZZrabufZZ. Click its cowsay (↹) button.

Problem

The first editor's title has now reverted to fubar, ignoring the formatting specified by the resourceLabelFormatter.

Now, if you click the cowsay (↹) button again, the other editor's title also reverts and becomes rabuf.

Expect

The editor titles should continue respecting the specified resource formatting, even after repeated calls to vscode.window.showTextDocument.

---

VS Code version: Code 1.73.1 (6261075646f055b99068d3688932416f2346dd3b, 2022-11-09T04:27:29.066Z) OS version: Windows_NT x64 10.0.22621 Modes: Sandboxed: No

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz (16 x 2400)| |GPU Status|2d_canvas: enabled
canvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_renderer: enabled_on
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: disabled_off| |Load (avg)|undefined| |Memory (System)|31.73GB (8.81GB free)| |Process Argv|--crash-reporter-id 3ee742d4-1f45-4a7e-a3d2-f8bab955b8ab| |Screen Reader|no| |VM|0%|

Extensions (30)

Extension|Author (truncated)|Version ---|---|--- Bookmarks|ale|13.3.1 ascii-tree-generator|apr|1.2.4 transformer|dak|1.12.1 vscode-jq-playground|dav|4.3.5 vscode-eslint|dba|2.2.6 xml|Dot|2.5.1 gitlens|eam|13.1.1 prettier-vscode|esb|9.10.3 lex-flex-yacc-bison|fau|0.0.3 auto-close-tag|for|0.5.14 kaitai-struct-vscode|fud|0.8.1 jq-syntax-highlighting|jq-|0.0.2 vscode-JS-CSS-HTML-formatter|lon|0.2.3 rainbow-csv|mec|3.3.0 vscode-aql|mon|1.7.1 vscode-docker|ms-|1.23.1 csharp|ms-|1.25.2 isort|ms-|2022.8.0 python|ms-|2022.18.2 vscode-pylance|ms-|2022.11.40 remote-wsl|ms-|0.72.0 cpptools|ms-|1.12.4 vscode-gitextensions|pmi|1.1.0 java|red|1.13.0 vscode-yaml|red|1.10.1 rust-analyzer|rus|0.3.1301 code-settings-sync|Sha|3.4.3 vscode-lldb|vad|1.8.1 vscode-java-debug|vsc|0.47.0 scriban|xoo|1.2.1

A/B Experiments

``` vsliv368cf:30146710 vsreu685:30147344 python383cf:30185419 vspor879:30202332 vspor708:30202333 vspor363:30204092 vstes516:30244333 vslsvsres303:30308271 pythonvspyl392:30443607 vserr242:30382549 pythontb:30283811 vsjup518:30340749 pythonptprofiler:30281270 vshan820:30294714 vstes263:30335439 vscorecescf:30445987 pythondataviewer:30285071 vscod805:30301674 binariesv615:30325510 bridge0708:30335490 bridge0723:30353136 cmake_vspar411:30581797 vsaa593cf:30376535 pythonvs932:30410667 cppdebug:30492333 vsclangdc:30486549 c4g48928:30535728 dsvsc012cf:30540253 azure-dev_surveyone:30548225 pyindex848cf:30577861 nodejswelcome1:30587005 282f8724:30602487 gswce1:30612156 iaj6b796:30613358 dbltrim-noruby:30604474 f6dab269:30613381 ```

[jrieken]

Merge this into the cowsay example's package.json

That API is still proposed, so I am surprised it works at all by just pasting this. Did you also enrol into the corresponding proposal?

[jrieken]

@isidorn who owns this now?

[kahlkevin]

Merge this into the cowsay example's package.json

That API is still proposed, so I am surprised it works at all by just pasting this. Did you also enrol into the corresponding proposal?

Interesting. And I'm surprised, in turn, to find out it's only still "proposed." To wit, it's documented as part of the contribution docs here with no mention of proposed status and, more importantly, it seems to work (modulo this bug report) in non-preview builds, so... not sure how an extension developer is supposed to know it's not fully supported yet...? :smile:

In any case, would be lovely to see a fix if indeed the idea is to keep the feature in the production product as a fully fledged extension feature.

Also, fwiw, what I'm really after is a way to specify my TextDocumentContentProvider's scheme's editor language id / mode. The relevant openDocument api doesn't give me the ability to provide one. This, in turn, seems to force me to either a) add a specific "file" extension to my scheme's uri's for my virtual documents, or b) modify the user's settings to specify the language mode for each of my virtual documents. Neither approach is appealing, but at least with approach a) I'm able to modify the URI presentation to "hide" the "file extension"... or so I thought. If you give me a better way to specify the language mode here, then I can avoid the need to use a resourceLabelFormatter in the first place...

[jrieken]

add a specific "file" extension to my scheme's uri's for my virtual documents

What's so bad about that? That's how "normal" files work as well

[isidorn]

@jrieken this was owned by Jackson. And I think once he left the team it passed on over with the explorer to @lramos15

[kahlkevin]

add a specific "file" extension to my scheme's uri's for my virtual documents

What's so bad about that? That's how "normal" files work as well

Well, "bad" isn't exactly the term I'd use. I'd call it inappropriate: definitionally, virtual documents aren't files and, so, it's kind of unfortunate to force them to adopt file extensions just to activate a language mode when all of the other overrides for openDocument provide for specifying the language id. Heck, even createOutputPanel lets me create a read-only document - without a file extension - while also specifying its language id.

In my case, the virtual document is not a file and I don't want to give the impression - visually or otherwise - that it is. Also, as a secondary concern I don't want the tab bar to be more cluttered or the tabs wider than they really need to be.

I want to have a singleton view and I want to show output from the "most recent" run of my custom command. My editor title wants to be something like "Most Recent Result". The output format happens to be JSON, so there's no real reason for me to construct a custom web view and, indeed, it's a better experience for my end-user to be able to use the native editor rendering and features relating to JSON documents. One could argue that an output panel is appropriate, and I agree, however my output is long (not wide) and doesn't lend itself as well to being locked away in an oft-hidden bottom panel. One could also argue maybe it should be a custom view so that it can be docked in a side panel... except again this is just plain-ol' JSON... so why would I want to go create a custom rendering view, when I have an excellent JSON editor/renderer already built into VSCode?

So, yeah, it'd be lovely if I could just open my virtual document by custom-registered scheme and assign it 'jsonc' language mode all in one go, without having to artificially apply a file extension that I don't really need or want.

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[kahlkevin]

@jrieken I'm a little confused as to what aspect of this issue has inspired you to convert into a feature request and make subject to voting/closure. Can you help clear this up?

I've originally reported a feature bug (in resourceLabelFormatter), and not a proposal for any new functionality:

• Either in a feature you consider to be in 'proposed' status, in which event a previous case for the feature will have been made already (otherwise it wouldn't exist?)... so, there shouldn't be any need to re-justify its existence.
• Or in a feature that shows some evidence of being in a 'production' status:
  • Presence in online documentation without any signaling of incomplete/preview status
  • Presence in production (non-insiders) builds
  • Lack of protection behind enabledApiProposals or any other similar mechanism

There may be some ideas I've articulated in follow-up discussion that you might perceive as new feature proposals and -- if you think it worthwhile -- I'd be happy to submit those ideas separately. But the core of this issue remains a bug report in existing functionality. I believe this issue should be moved back to a bug workflow and ultimately be repaired, regardless of the merits of anything else aside from the bug report discussed here.

Can you help clarify what's going on with this bug? Thanks in advance!

[vscodenpa]

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodenpa]

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!