findFiles but instead of a glob language:markdown like in onLanguage actiovation event

[TomasHubelbauer]

Hey, I'd like to get all MarkDown files in a workspace for my extension so I can index them and enable my extension's functionality based on the index. Currently I am using workspace.findFiles followed by workspace.openTextDocument to get the contents. This works fine, however:

To get all MarkDown files using findFiles, I have to use a glob like **/*.md. This will not capture all files for which VS Code would trigger the onLanguage:markdown activation event, because VS Code will recognize even MarkDown files with extensions like .markdown and others.

I would like to propose extending the findFiles API in a way which allows filtering by the detected language, not just a file glob. In my view something like findFiles('language:markdown') would be a good proposed API, but maybe an overload or a different method will have been found to be a better choice.

I know I can extend my glob to include multiple extension, all of which VS Code will detect the MarkDown language for, but I think it would be better to have this set in one place and it already is in the API, so it makes sense to reuse it.

[roblourens]

I don't know if there are enough general usecases for this to consider it as API. Users can associate any file extension to a language with "files.associations" which might be unexpected.

What do you think @jrieken?

[TomasHubelbauer]

@roblourens Is there a way to get the internal associations merged in with files.associations in the extension code programatically? That would meet my goal as well as I am wary of duplicating the sets of associations in two places and want to be consistent with VS Code, so obtaining it from VS Code would be enough, I can construct the glob from it afterwards.

[vscodebot]

This iteration we focus on issue grooming. 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!

[TomasHubelbauer]

@roblourens can you reconsider with respect to #48674?

[roblourens]

I'm not sure what you mean.

[TomasHubelbauer]

What I am suggesting is that adding an overload with either the aforementioned syntax language:markdown or even an actual DocumentSelector could be a solution for avoiding BC in the ticket I mentioned.

[roblourens]

I think these are very different issues, I don't see how fixing this impacts the other one.

[TomasHubelbauer]

Sorry, you are right.
I got my issue mixed up, because I would benefit from both mentioned in my workaround for the other issue.