Expose FileSystemProvider stat information to the resource when clause

[plus-]

Feature Request:
Right now the when clause context for resources is limited to resourceScheme resourceFilename resourceExtname resourceLangId

When implementing a FileSystemProvider, it would be usefull to either be able to hook a function from the provider to the when clause context, or at least expose the result of the provider stat function for any given resource in order to use one of our custom boolean properties.

Use case example:
Implementing a remote fs that supports locking resources, I would like to implement explorer contextual menu actions (lock or unlock) that are filtered based on the lock status of the resource.
This is the same idea behind any permission based actions.

[jrieken]

Implementing a remote fs that supports locking resources,

Hm, the fs provider API doesn't support locking... How would you represent that in the stat model?

[plus-]

Well since any provider can extend the stat model it could be a non issue.

For example in my fileSystemProvider stat is returning my own implementation of the FileStat to add some custom properties like isCheckedOut

Now I'm not sure how the when clauses are evaluated (is there a templating engine?), but my thinking was we could expose the stat result to do something like:

stat.name == foo or in my previous example we could evaluate on the fly when we right click:

"menus": {
    "explorer/context": [{
        "command": "cmis.cancelCheckout",
        "when": "resourceScheme == cmis && stat.isCheckedOut"

Hope it make sense

[jrieken]

Well since any provider can extend the stat model it could be a non issue.

It actually is because the extension runs in a different process than the UI - in which context keys are evaluated. So, this actually is the challenge...

[vscodebot]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!