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.

hnw/vscode-auto-open-markdown-preview#2
hnw/vscode-auto-open-markdown-preview#7
hnw/vscode-auto-open-markdown-preview#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?

[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

[mholtzhausen]

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

Or close all diff views on commit

[phil294]

This issue would have been resolved with what was discussed in #85237: Adding a setting to always open working tree files in preview mode

the issue got closed by vscodebot though, so... whatever

[aapis]

Still would support this feature, but as a workaround I've stopped using the built-in git integration. Works great!

[taiya]

This issue would have been resolved with what was discussed in #85237: Adding a setting to always open working tree files in preview mode

the issue got closed by vscodebot though, so... whatever

Right, but that issue's title is incomprehensible...
We have ~40 +1 in this thread, how can we escalate and have the two issues merged?

@phil294 what do you use instead?

[phil294]

@phil294 what do you use instead?

@taiya I simply accepted my fate and set workbench.editor.enablePreview to true and learned to live with it, which I think is the only feasible way to use vscode with git integration

[andreascian]

Still would support this feature, but as a workaround I've stopped using the built-in git integration. Works great!

edamagit rules!! 👍

[dlong500]

@joaomoreno I hate to (also) be that guy, but this issue has been hanging around for far too long (4+ years). Can we get some traction on at least a path forward with some options? Honestly at this point I'd be happy with a setting that would simply hide any working tree editors unless you are in the source control view. It just makes no sense whatsoever to have to manually close a working tree editor in the explorer view, and I haven't seen any reason presented why anyone would actually want the current behavior.

[joaomoreno]

@dlong500 It's not that we don't care to fix it. But rather the large scope around the fix and the dependency on API, since git is an extension itself. This is blocked by #15178.

[taiya]

Thanks for the diplomatic answer Joao, can we do anything on our side to speed up #15178?
This UI "bug" is one of the worst behaviors in the whole vscode IMHO.

Thanks!

[dlong500]

Thanks @joaomoreno. I do want to clarify that I'm really not trying to be critical of vscode overall. I love the app and appreciate all the amazing work that has been done these last many years by you and other developers. This is just one of those things that I deal with literally every day so I would hope it would be taken off the backburner. This is really the only thing that truly bugs me about using vscode. If I could contribute anything useful towards a resolution I'd certainly offer my limited skillset as well.

[omidantilong]

Adding another voice to this. Does it really need to be so complicated? It seems like a lot of time has been spent thinking about the context in which to show the diff editor, intelligently closing it etc.

It doesn't have to be smart. Literally just something in the command palette that will close any tabs with (Working Tree) in their name would more than suffice at this point.

EDIT: I had a go at building an extension to achieve this and ended up down a rabbit hole. Looks like there is a bunch of work being done at the moment exploring how to work with open tabs programatically.
#15178
#139607

If the resulting API changes include a tab.close() method (as is proposed) then this should be relatively straightforward...!

[lszomoru]

Today's Insiders release (2022-02-10) contains a new setting (git.closeDiffOnOperation) that is meant to address the need to manually close the diff editors after certain git operations. If the setting is enabled, diff editors will automatically be closed when changes are committed, discarded, staged, unstaged. Try out the new setting and let me know your feedback.

[taiya]

@lszomoru that's a good first step, but it would also be great if diff windows were limited to the "Source Control" tab?
(i.e. hidden and/or closed when you move to the other modes? explorer, search, ...)

[dlong500]

@lszomoru I agree with @taiya
It's a good step, but doesn't resolve the issue if you've looked at a diff but haven't performed any git operation yet. If the diff editors only showed up in the source control tab all the time then it would resolve the clutter in the normal editor tree. I'm glad to see some progress but I don't want this issue to get closed out without a full resolution. The OP issue is actually a narrower case than what this thread evolved into, because the diff or special case editors cluttering up the tree is what most people seem to be dealing with (regardless of whether an editor is stale or not).

[lszomoru]

Today's Insider build (2022-02-16) also contains a new command, Git: Close All Diff Editors that is available in the command palette and can be used to manually close all diff editors (both index, and working tree) independent of the value of the git.closeDiffOnOperation setting.

As for the request for the diff editors to only show when the SCM viewlet is active, I am most certain that its not currently possible. There is currently no support to associate an editor with a particular viewlet so that it is only being shown when the viewlet is active. This in scope is also greater than just SCM - imagine that you open the Extensions viewlet, search for an extension, and you click on it to show its details. It would be nice if the extension details editor would only show when the Extensions viewlet is active. I have filed a separate issue to track adding support for associating an editor with a viewlet.

[lszomoru]

I am going to close this issue for now, while the concept of associating an editor with a viewlet is being discussed in the linked issue. If you are passionate about that, please add your feedback to that issue. In case there is a positive resolution of that issue, we can adopt that capability for the diff editors.

[dlong500]

Just a note that the newer related issue #143193 is now officially a candidate for the backlog of feature implementations, but it needs 20 upvotes to pass the threshold. Please head over there and upvote if you haven't already.