Do not specify language IDs for data sets opened in the Zowe Explorer v3 tree view

[benjamin-t-santos]

Is your feature request related to a problem? Please describe.

In v2, Zowe Explorer downloaded sequential data sets to temporary on-disk storage. These downloaded files had extensions (.cbl, .pli, etc.) that allowed extenders to associate the extension with a language.

In v3, data sets are associated with a language by Zowe Explorer using the VS Code API. In onDidOpenTextDocumentof DatasetFSProvider, opened documents have their language set to the ID returned by getLanguageId(parentPath). For example, PL/I programs have their language set to pli.

Not adding a file extension prevents extenders or users from specifying their own file associations. Setting the ID forces extenders to register languages in their extension manifest with the same language IDs as Zowe Explorer to have their extension recognize data sets opened in the tree view.

Describe the solution you'd like

Zowe Explorer should not decide the language ID for data sets. Extenders should decide this - either by providing an extension for data sets opened in Zowe Explorer (as was done in v2) or by granting users access to the DatasetFSProvider to specify their own language IDs.

Describe alternatives you've considered

You could request extenders to register new languages that use the exact IDs Zowe Explorer uses. I am not sure how else to satisfy the file associations problem.

Additional context

If a solution is agreed upon, I'd be happy to help contribute.

[github-actions]

Thank you for raising this enhancement request.
The community has 90 days to vote on it.
If the enhancement receives at least 10 upvotes, it is added to our development backlog.
If it receives fewer votes, the issue is closed.

[phaumer]

Zowe Explorer should be completely language agnostic without trying to guess extensions or language ids.

Language ids are case sensitive and we had discussion in the past between the vendors about which variant to use to avoid conflicts. E.g. in this issue it was mentioned that Microfocus was using COBOL, IBM was using cobol and Broadcom wanted to use a different name such as Cobol or che4z.cobol (decision was not posted): IBM/zopeneditor-about#70

[traeok]

Hi all,

After discussing with the squad, it makes the most sense to use the previous behavior from v2 where we assigned a file extension to data set resources. I've made some changes in #3127 to add those extensions back - this should allow LSPs to continue leveraging file associations as usual.

As a side note, we would like to hide the file extension from the breadcrumbs/tab for a cleaner UX, but we'll have to wait for the custom tab labels to be available for developers until we can do so.