Can we avoid creating extra text documents during batch refactors?

[mjbvz]

Related to #64485

repo

1. In a large workspace with no editors open
2. Do a workspace find replace for a common term

Bug
Observe that for each edited file, VS Code emits a onDidOpenTextDocument and then onDidChangeTextDocument. A bit later onDidCloseTextDocument is emitted when the documents are cleaned up. None of the files are even opened in text editors

---

When doing bulk edits/refactors on unopened files, can we avoid creating text documents that are exposed to extensions? I think extensions should be using file watching for these cases instead

If changing the behavior is too risky, maybe we could have a flag on these events so extensions can easily ignore them?

cc @andrewbranch

[RedCMD]

I agree
having background documents spam extensions is rather annoying
I would prefer flagging the reason why a document was open

I assume you mean ctrl+shift+f SEARCH?
not ctrl+f find

title says fine btw

[jrieken]

I'd say that is by-design and I wouldn't tamper with how or when these open/close events are fired. Some documents might already be open, some might stay open but be ignored.

@mjbvz @andrewbranch So far the issue just describes behaviour but what is the actual problem here?

[andrewbranch]

It’s a lot of unnecessary work for TS Server. In the case I noticed, I was changing hundreds of closed files, none of which were part of any tsconfig project I had open. For each open/close, TS Server (in addition to parsing/binding/project creation/module resolution) installs (and then almost immediately uninstalls) file watchers for all the resolutions that occur in the open files. But TS Server only does this work because the editor says the file is being opened (meaning a user might interact with it), which is false.

[jrieken]

But TS Server only does this work because the editor says the file is being opened (meaning a user might interact with it), which is false.

Thanks for clarifying. The onDidOpenTextDocument might not be what you want, it fires whenever a document is opened as in "read from disk", not necessarily opened in an editor. A better API to approximate "user interacted" is the tabs-API (vscode.window.tabs) which allows you to know if there is actually an active or "passive" editor for a resource.