Vscode: Git: stale editor inputs hanging around

[bpasero]

I am seeing multiple editors in index and working tree hanging around even though those are no longer valid:

[joaomoreno]

There's no control of this from an extension side. The current API has:

• provideContent(): string
• onDidChange(): Event<Uri>

What I would need is an onDidDispose event. I need a way to tell someone that a specific resource I once provided content for no longer exists. We could then do the right thing throughout the workbench.

Thoughts @jrieken @bpasero ?

[jrieken]

Unsure what to do there. The API just talks about content provider so I am unsure if they should be allows to define the lifecycle of the document...

Maybe the issue is that we don't have a nice dispose story for virtual documents. @joaomoreno Would it help if we start to dispose virtual document more clever? So start to ref count them and instead of the 3mins rule we could say virtual documents get disposed when they aren't 'used' anymore - where used means on the extension host not referenced anymore and on the main side not visible anymore.

[joaomoreno]

That does work if the extension also participates in the ref counting. 👍

[jrieken]

I can investigate...

[bpasero]

@joaomoreno @jrieken did you guys figure out a solution? I think today the experience is pretty bad with diff editors piling up from working tree and index even though I already committed my stuff. I think we need an explicit way for extension (or any document provider) to indicate when a resource is no longer valid. I would need the same once files:// adopt this because a deleted file is also no longer valid and should result in the editor being closed (at least that is our behaviour today).

[jrieken]

Last time I talked to @joaomoreno we figured its the workbench not releasing the inputs but I could be wrong

[joaomoreno]

@jrieken The workbench doesn't know when it can release the inputs. There's a concept missing: the death of a Resource, regardless of how many people are holding on to its TextModel.

[jrieken]

Is this still an issue? Do inputs couple their lifecycle to editor model references? My understanding is that with the latest change @bpasero did the input just holds a reference and doesn't look at what models are alive

[bpasero]

I think the missing concept is still that a resource text content provider can signal any editors associated to a resource should be disposed because the resource is no longer valid. When I commit my changes I would expect any input that I opened from that commit to close (e.g. diff editors). Not sure though if this is a concept we need to add as API to extensions or rather the SCM viewlet being the one that closes any editor opened as soon as there are no more outgoing changes in a group.

Since for example the FileEditorInput has adopted model references, it owns the lifecycle of that reference: when the editor is closed, it disposes this reference. There is extra code around file editors that will trigger closing of editors when a file is deleted on disk.

[ProLoser]

FYI: I use an auto markdown preview extension which had a similar problem. Closing the source document that the preview pane is created and synchronized with doesn't close the corresponding preview. Additionally, opening multiple documents can sometimes mess up or shuffle tabs around. I'm not sure if it's relevant but it may be helpful to keep that in mind so that other developers are able to handle these problems more easily too.

https://github.com/hnw/vscode-auto-open-markdown-preview/issues/2
https://github.com/hnw/vscode-auto-open-markdown-preview/issues/7
https://github.com/hnw/vscode-auto-open-markdown-preview/issues/10

[jessejanderson]

Is there any progress on this? New user to VSCode and it's a little annoying and weird that I have to close these all the time. Even if it wasn't automatic I would love even just a Close all working trees command that would close them so I don't have to do it manually every time.

[dlong500]

To me at the very least it would seem appropriate to have all "working tree" editors grouped in their own tree in the explorer pane, possibly with an option to hide that tree entirely unless you are in the "Source Control" view. This would greatly reduce the clutter and grunt-work of closing those editors all the time.

[ericnewton76]

Also, its bizarre discarding changes made by my cat's paws on the keyboard from the night before, and still seeing the changes in the document after going to Source control pane and Discarding Changes on that file.

Obviously the problem here is the cat trying to code and not knowing basic syntax and grammar, however, the Discard Changes feature I would intuitively expect it to also revert the changes in the opened document tab (or ask to revert?)

Instead the changes are still visible in the document tab, even though the underlying file has been reverted. And, you could end up with an unintended Close-All,Theres-Modified-Files-Not-Saved type scenario that could possibly reintroduce "speculative code" within files, and need to Discard Changes yet again on that file.

[OneOfOne]

I hate to be that guy, but any news?

[spacewaffle]

Still looking for something on this. Anything new?

[joaomoreno]

@jrieken I wonder if we're now closer to fix this?

[jrieken]

not really - you can be a file system and send a delete event but I think that will make us keep the editor input anyways

[dlong500]

Regardless of whether an editor is "stale" or not, is there a way to accomplish my earlier suggestion of at least grouping all these working tree/index editors within their own tree rather than scattered among the other editors? I personally don't ever see a use for these editors unless I'm in the source control pane (at which point they are handled differently anyway).

[aapis]

Also hoping for a solution here in a future release. 👍

[rysport]

Seeing that this issue is now two years old, would it be possible to implement what @dlong500 suggested for now?

[maxcct]

Just going to throw an additional voice behind this request. Ideally I'd like to have a setting that would make working tree editors close themselves automatically as soon as another editor is switched to. Otherwise I always end up accumulating a silly quantity of open working tree editor tabs.

[jjhampton]

I'd love to see this request implemented as well. VSCode is the only code-editor I can think of that has this functionality - you inspect some files in the VCS editor to see what the diff is, but after you're done, there are multiple 'working tree' file views left open that have to be manually closed.

[OneOfOne]

Almost 3 years later and no comments :-/

[rolandas-valantinas]

Over 3 years now!
This extremely annoying and prevents using opened tab limit - while checking for changes it closes actual development tabs!

[taiya]

I add myself to the list of gripes.
In some editors code diffs are a (globa) "toggle" somewhere in the UI.
Keeping an open tab for them is crazy!

[rolandas-valantinas]

Can we just have option for diff to open in new window? So we at least could close all of them in one go!

[taiya]

I think have diff tabs hide when you exit the "Source Control" mode (vs.
Editing, Search, ...) would likely be the best.
In fact perhaps all open files should have diff enabled in that mode?

[leventku]

I like the enablePreview: false mode but diff tabs getting too much accumulated. I think this should be managed better in vs code, either with this feature or some other way.

[sethrevelle]

Love VSCode, this is my biggest gripe though. Workflow of double checking changes, before committing is made...... painful because of the lack of any way to close all working tree files.

[andreascian]

I think have diff tabs hide when you exit the "Source Control" mode (vs. Editing, Search, ...) would likely be the best. In fact perhaps all open files should have diff enabled in that mode?

I got the same idea: there should be an option to close all diff tabs when going out of source control mode