Show an editor only when a particular viewlet is active

[lszomoru]

It would be nice if we could explore associating an editor with a particular viewlet so that the editor is only being shown when the particular viewlet is active. There are multiple possible applications for such a feature:

• SCM - only show diff editors when the SCM viewlet is active
• Extensions - only show extension details editors when the Extensions viewlet is active

[bpasero]

so that the editor is only being shown when the particular viewlet is active

How would that work exactly UX wise? Would editors literally close? What if I only have diff editors open from SCM and click on the explorer?

//cc @misolori

[lramos15]

We did the opposite in the hex editor and showed the hex viewlet whenever a hex editor was active and people didn't seem to like that too much. I think this might be similarly annoying but should be somewhat feasible with the tabs API. You would lose some scroll state and what not

[lszomoru]

This request has come up from two separate users as feedback on the feature to automatically close diff editors:

• Git: stale editor inputs hanging around #18651 (comment)
• Git: stale editor inputs hanging around #18651 (comment)

[bpasero]

@lszomoru those comments do not really go into detail of how this would work end to end, especially from a user experience point of view.

[miguelsolorio]

I think because our editors work so independently of any views that this might complicate the UX. It's not like in MS Teams where each "view" has a full master-detail page associated with it.

I think one way to alleviate this is to provide a setting that would close certain editors when those views are not focused (i.e. diff views) but i wouldn't expect it to re-open on its own.

[dlong500]

I think one way to alleviate this is to provide a setting that would close certain editors when those views are not focused (i.e. diff views) but i wouldn't expect it to re-open on its own.

@misolori Honesty in my opinion I think an option to automatically close the various git action editors when switching out of the source control view is perfectly fine. I can't think of a reason why I would need/want to have the specific editors re-open when switching back to the source control view. I typically use those types of editors as transient information anyway. I could be missing some specific scenario where it would matter, but in any case that would be a good first step to see how the workflow plays out because it would be optional via a setting.

[taiya]

+1 for this feature

e.g. code-diff tabs (and layout) have nothing to do with code-editing, and I always find it awkward to swap between the modes. Pushing my support for this to get resolved, as #143193 was closed. Would be a huge improvement to day-to-day vscode use.

The biggest challenge is that having side-by-side editors is very common, yet when you open a code-diff you get a side by side inside of a side-by-side (hence 1/4 screen), which is impossible to read. So it seems reasonable to me that the code review view has its own layout manager, so not to interfere with the editors?

[bpasero]

Based on these ideas, a scenario for how this would work is:

• you open SCM viewlet
• you open a couple of diff editors from the changes view
• you click on Explorer viewlet
• all diff editors "associated" with SCM viewlet close
• you click into SCM viewlet
• none of the previous diff editors restore

A related consequence is that if you have a dirty SCM diff editor, you first get asked to save or discard that editor before you could open the Explorer viewlet.

Hiding the side bar probably does not count here and would preserve the editors. And opening any other viewlet would also not count, only the explorer does?

[miguelsolorio]

A related consequence is that if you have a dirty SCM diff editor, you first get asked to save or discard that editor before you could open the Explorer viewlet

My initial expectation is that a modified diff editor would remain, since you have made changes, where the regular diff editors that are only being viewed have more of an ephemeral state and are ok with them being dismissed. But it's worth trying out to see how the UX feels.

[bpasero]

Knowing which editor belongs to which viewlet is also not easy: in this case the editors are opened from the Git extension with a specific git related scheme, so this would probably even require some kind of API to figure out.

Maybe a pragmatic solution would be to simply close any editor that does not have a file from the explorer opened once you click back into the explorer. This would include almost all editors, except the files you opened.

[lramos15]

What about with extensions? Would I go to the marketplace click on an extension and then if I go back to the explorer it gets auto closed on me? I feel like this setting would have to be per viewlet as well and seems like it should be specific to the view to implement since in theory the git extension knows which editors its spawned and could utilize the tabs API to see if they're still open.

[bpasero]

Yeah that is a good point and I was never a big fan that an extensions editor would stay open when I go back to the explorer. I am still trying to figure out a generic solution that could work without having to add new API. Maybe switching viewlets via sidebar could simply restore all editors as they were when the viewlet was changed?

For example:

• the explorer is visible and you open 3 files
• you then click on extensions viewlet
• the 3 files close because this is a new "context"
• you open 2 extensions
• you click back to explorer and the 3 files you had opened restore, the 2 extensions close
• you click on changes view and all editors close because of the "new context"
• you open some diff editors
• you click back to explorer and again the 3 files restore

In other words: each viewlet has a dedidcated set of editors that are open. You are free to open a SCM diff editor while the explorer is visible, so it is not so much tied to the kind of editor but more tied to what viewlet was visible when the editor was opened.

[dlong500]

Any chance we can "transfer" the upvotes from the other issue to this one? It already has 47 votes. I'd hate to see this get lost in the shuffle if a number of people aren't monitoring the threads (especially since the original issue has been around for a while).

[vscodenpa]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!

[dlong500]

@bpasero I'm confused about what is happening here. I just came back to check on this and now see it is tagged "out-of-scope" and apparently abandoned. There was so much discussion and time that went into the original issue, and then it finally cleared the bar of sufficient upvotes to get added to the backlog. What exactly happened?

I'm on the insiders release and see no changes from the basic problem I've always been facing--when selecting a changed file in source control view and then going back to the explorer view there is a comparison editor open in the editors tree. Am I missing some new setting that makes this issue moot? All I've wanted is the basic ability to hide or not show comparison editors in the explorer view that were automatically opened as a result of viewing changed files in source control view.

EDIT I should mention that I've reviewed the "out of scope feature requests" section of the docs and don't really see why this one would have been closed. It seems like it met the standard thresholds for consideration and also seems like it would be a pretty simple fix that wouldn't take developers very long at all to address (especially just an option to auto-hide comparison editors that were opened as a result of a source control selection).

[movy]

Is this issue concerned with lingering "working tree" copies of a file? Case in point: whenever I try opening a file using Go to file command, in the Recent section I can see "working tree" (diff) copy of a file, but to open the actual file I have to type almost its entire filename:

There's no obvious way to re-open the original file from its diff view. I have a shortcut forGit: Open file command, but even this command fails lots of times, and I have to clear my recents to reach the original file via otherwise very convinient Go to file function.

I've been googling this annoyance for years, and this issue seems to be the closest to my experience. Would be nice to have it prioritized finally.