MarkdownWorkspaceSymbolProvider opens all .md files in the workspace as documents

[chrmarti]

That triggers linters and other decorators on Markdown. I don't see any other types of files behaving the same. Maybe the symbol provider should not use documents? /cc @DavidAnson

[mjbvz]

Yes, we can use fs to read these files if they are local. @jrieken is this what we should do or is there a better approach that will properly support markdown files from file system providers?

[jrieken]

What you need is #48034 but for now there is just fs...

[borekb]

Could this issue be causing that I see a lot of issues in Markdown files right after VSCode starts, before I open any file?

I have quite a few extensions for Markdown files but I don't think they should trigger automatic checks on unopened files.

[TomasHubelbauer]

My extension, MarkDown Link Suggestions, uses openTextDocument which I was recently notified (#58933) causes some internal workflows to trigger and it may be that the MarkDown workspace symbol provider does the same thus this weird behavior. Long story short it should not be used to just read the file's content. I scan the whole workspace on activation, which happens in case the workspace does have any MarkDown files, so I do that full workspace scan by design, but the only result from that should be my diagnostics, the markdownlint ones may be caused by me opening the MD files and then them getting diagnosed by markdownlint as a result.

I initially used it because I figured there was no harm in pre-warming the files and getting the nice TextDocument interface to work with (free uri and lineAt) and that VS Code would dispose of them if it there was a problem, but I didn't know it would cause some hidden behaviors.

I will in the meanwhile, waiting for #48034 to land, use fs.readFile, but I still need to use MarkDown document symbol provider, which I suspect will have the same behavior and the workspace one so it may not have any positive effect.

Worth the shot though :-)

[solomatov]

It seems that it's impossible to fix it cleanly with the current API (the other solution is to hardcode all extensions from markdown-basics). To understand whether file is md or not, we need to get its type by URI. But there's no such API. Do you mind if I contribute a PR here?

I am thinking about adding vscode.workspace.getLanguageId(uri: vscode.Uri). Does it seems legit?
@OmarTawfik

[solomatov]

Another idea which is cleaner than hardcoding but worse than API is to do the following:

• we can go to the extensions directory (I assume that all extensions are in the same folder) and go to package.json of markdown-basics. We can extract extensions from there and use them to check whether it's markdown or not.

@jrieken what do you think? Should I proceed with this hack or create an API for languages? Concerning API for languages, we might expose more information about them, since I am sure that other extensions will need them.

[solomatov]

After talking to @OmarTawfik it seems that the API isn't necessary. Only .md extension is used for watching documents, so we can just hardcode it. It's a rather simple change.

[mjbvz]

Fixed by #80506