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 :-)