Conditional Visibility Check for Custom View and resourceLangId

[pltrant]

• VSCode Version: 1.14.#
• OS Version: Windows 10 Pro, 64-bit

I'm using the new when condition check for custom views (#29436) and for a check against resourceLangId, it doesn't appear to be working all the time. Specifically, if I open VSCode and it restores the windows from a previous session, it doesn't display the custom view even though the current file matches the language ID. Sometimes, after clicking around various documents, opening/closing new ones, it will finally show up.

Does something need to happen to set the resourceLangId when launching VSCode? The extension is for a custom language, which detects files from the filenamePatterns in the package.json. Is the resourceLangId not checking against it or is the URI not being set properly from it so that resourceLangID is set?

"contributes": {
    "languages": [
        {
            "id": "nzq",
            "aliases": [
                "NZQ",
                "nzq"
            ],
            "filenamePatterns": [
                "N[0-9][0-9][0-9][0-9][0-9]"
            ]
        }
    ],
    "views": {
        "explorer": [
            {
                "id": "TestViewID",
                "name": "TestViewName",
                "when": "resourceLangId == 'nzq'"
            }
        ]
    }
}

So using this setup, if I have a file open that has a filename of N93845, the editor does recognize it as belonging to the nzq language, but the custom view isn't showing up.

[pltrant]

@sandy081, attached are some screenshots and an animated gif to demonstrate the issue. I've seen it work and not work at various times. In the animated gif, it finally starts showing up after I open a folder, open a document, then switch back to the main document. Notice that the Editor recognizes the "NZQ" language pattern and is being used as noted in the bottom, right status bar. Let me know if you need any other details, as I'd really like the ability to hide custom views when not necessary.

[pltrant]

Tagging @jrieken since this is probably more of an issue of how resourceLangId is set.

[sandy081]

@pltrant You pinged the right person.

@jrieken Can you please take a look at why the resourceLangId is not picked always?

[jrieken]

It depends on the context key service you are using... There is usually one per editor and one for the sidebar. I assume you are using the latter which means it depends on the explorer selection. Unsure if that makes sense and unsure if the resourceLangId should be implemented there...

[sandy081]

Hmm understood.

So, I have to use the context key service from editor irrespective of where resourceLangId is defined?

How can I get such a service?

[jrieken]

So, I have to use the context key service from editor irrespective of where resourceLangId is defined?

It doesn't work like that. The resourceLangId is defined only once but there multiple values associated to it. Think of a tree of context key values, only descendants see values from their containing context key service. So exposing a context key value "side-ways" from an editor to the sidebar doesn't make much sense. There is no definite answer here. Maybe a new context keys that only lives in the global/root context key service is needed, something like activeResource and that must be updated whenever the active editor or explorer updates...

[sandy081]

Got it. Thanks.

[sandy081]

This is as designed now. To need a change we need to have support for global context keys.