Closed File Violations Stay in Problems Pane

[wchisenski]

When I close a markdown file in VS Code, it's common for the filename and violations to continue to be listed in the problems pane and I haven't been able to determine the reason. There are times when I close a file and the corresponding item(s) in the problems pane are immediately removed, other times it removes them after some amount of time, and sometimes they are not removed until I restart the extension.

What is the expected behavior and is there a configuration setting that ensures these are cleared when the files tab is closed? I work on lots of markdown content, and it can be confusing when you see a number in the problems pane (indicating an issue) only to open it and see that it's for the previous file you were working on, not the current file.

In the image below, the it-dashboard-api.md file is closed, yet I still see it listed in the problems pane and the number is listed next to the file in the tree.

[DavidAnson]

I think this is the responsibility of Code to handle, but I can do a little research. Does it happen with any other extension?

[DavidAnson]

While I don't see any documentation outside vscode.d.ts, it looks like it is the extension's responsibility to clean this up. However, this extension does so rather unambiguously:

https://github.com/DavidAnson/vscode-markdownlint/blob/55658e4b011caa72440ce143d88936ee566386dc/extension.js#L977-L981

The delete method being called on that VS Code interface should do what's expected:

https://github.com/microsoft/vscode/blob/5d25f31b7e4d06a03698430ff0ee238d79eb7848/src/vscode-dts/vscode.d.ts#L6822-L6828

HOWEVER, I found this gem in the VS Code API comments, so I suppose it's every extension's responsibility to work around the unreliability of VS Code's onDidCloseTextDocument event:

https://github.com/microsoft/vscode/blob/5d25f31b7e4d06a03698430ff0ee238d79eb7848/src/vscode-dts/vscode.d.ts#L13428-L13429

Oooookay. :)

[wchisenski]

Hi @DavidAnson,

Thanks for looking in to this for me! It seems like this has been a long running issue for VS Code based on another report of the same behavior here: https://github.com/microsoft/vscode/issues/52348

As to your earlier question, while I didn't initially realize it -- yes I do see the same issue with other extensions like Code Spell Checker. Given what you've found, feel free to close this issue. Maybe in some future release they address the onDidCloseTextDocument event reliability.

[DavidAnson]

I looked into using onDidChangeVisibleTextEditors per the VS Code recommendation as a workaround for onDidCloseTextDocument being unreliable. However, that event only fires when the visible text editor(s) change, and so will not fire when a background text editor is closed. I don’t see any event in the VS Code API that’s better for finding out when a text document is closed than onDidChangeTextDocument, so I think the current extension implementation is correct and not easily improved. Once VS Code fixes this event’s inconsistency, the problem you report should go away.

[wchisenski]

Thanks again, @DavidAnson! I appreciate your work on this awesome extension for those of us who write a lot of Markdown in VS Code.