Could we have an option to stay in the current file when navigating back or forward using the following commands:
Currently, it navigates across all files, even the ones that have been closed.
I would like to add that this feature request might well be what most users expect. After all, VS Code is a tabbed view just like a browser is. When I hit "back" and "forward" in a browser I don't expect it to switch tabs either.
I guess you get the least surprising behavior by adding new commands workbench.action.navigateBackInCurrentEditor resp workbench.action.navigateForwardInCurrentEditor (not sure whether editor is the appropriate domain concept for "tab"). These could behave just like the existing actions, except they skip all the elements in the back-forward history that aren't in the current editor. This way you keep a single global multi-tab back-forward history which can be linearly understood.
I dove into the code a bit, and my impression is that implementing this would be roughly being the inverse of setting acrossEditors do true, as described in https://github.com/Microsoft/vscode/blob/73f3eebe40f01e77751544f48dea8404230e1da9/src/vs/workbench/services/history/common/history.ts#L25
This looks like a relatively easy change to make, pretty much local to the history service. I'd love to contribute a PR for this, but only if there's a chance that it'll get merged. What's the best approach? Discuss first? Or just code it up, make the PR and discuss from there?
@Otiel @eteeselink so how would this work? The seed of the commands is the same as the current "Go Back" / "Go Forward" commands, but they would simply stop to work once either going backwards or forwards would jump to a different editor than the active one?
@bpasero Not exactly. It should stop only if there is no more history to go to for the current tab, and it should "jump over" the history of other tabs.
Consider this seed of cursor positions:
Tab 1, Ln 1, Col 1Tab 2, Ln 2, Col 2Tab 1, Ln 1, Col 11Tab 1, Ln 1, Col 111At that point, if the focus is on Tab 1 and I'm using the "Go Back" command twice, it should jump to Tab 1, Ln 1, Col 11 then to Tab 1, Ln 1, Col 1.
@Otiel but would you expect this to go all through one stack of history? Imagine you did go back once and it jumped over tab 2 but now you navigate forward with the normal "Go Forward", would you expect to end up in Tab2?
In other words: should this feature run from a completely separate history stack than the one we already use.
Imagine you did go back once and it jumped over tab 2 but now you navigate forward with the normal "Go Forward", would you expect to end up in Tab2?
No, if I'm in Tab1, I should stay in Tab1 whether I'm calling "Go Backward" or "Go Forward".
In other words: should this feature run from a completely separate history stack than the one we already use.
I would think that it would be easier to implement if there was one history stack per opened tab.
Is there still any possibility of this?
I also agree this should be a thing. For all ide's, dissasemblers, browsers, etc there is a navigate back and navigate forward (which i bind to mouse 4, mouse5). For vscode this isnt possible which is a little frustrating
I agree that the behavior of navigateBack and navigateForward in VS Code is frustratingly different than what I expect it to be. However can someone clarify if this issue is requesting an option for it to behave the way I want?
If I understand correctly, "editor" in VS Code's terminology refers to a section of the window that has its own tab bar, and the window can be split into multiple editors, for example by using View > Editor Layout > Two Columns. (Please correct me if I'm wrong here.)
What I'm looking for would be back and forward navigation within a single editor only. So it would allow jumping between different files in the navigation history, but only within that editor. This, incidentally, is the same way it works in Qt Creator in case that's helpful.
Is that within the scope of this issue? It sounds like what @eteeselink is talking about, but I'm not 100% sure, and there's also an open issue #45233 that might be what I want.
I would mention, sorting open editors by "most recently visited" would be useful as well (like CMD-E in IntelliJ). There, CMD-E auto selected the last editor every time, allowing one command to switch back and forth
Just to add 2 cents: I'd really love to see ability to navigate history within a single file. Current solution makes me to lose my focus so many times, that I typically just skip using it and browse files manually.
IMHO if you want to switch across files you use hotkey to access n-th file in your tab list (or eventually use ctrl+tab as a last resort).
I would like to add that this feature request might well be what most users expect. After all, VS Code is a tabbed view just like a browser is. When I hit "back" and "forward" in a browser I don't expect it to switch tabs either.
The difference though is that when clicking a link to a different site in a browser, you remain in the same tab, and can go back to the previous site with the back button, while in vscode you would go to a different, possibly existing, tab due to having one tab per open file.
Not that this function shouldn't be available.
No, if I'm in Tab1, I should stay in Tab1 whether I'm calling "Go Backward" or "Go Forward".
I would think that it would be easier to implement if there was one history stack per opened tab.
I would like to see this supported with buttons probably in the top right corner of an editor pane (region shown under tab bar for a selected tab):

I believe this would make the "history within this tab" behavior intuitive, and also quick to find when an action surprises by jumping to a different location.
Similar buttons are also suggested here but in reference to #42617.
go back should not switch tab, this is really bad UX
This would be super useful for reading code.
I often cmd+click some function to read them and then want to go back, but maybe in meantime I switch to other tab to read something else - not having history per tab is so annoying.
This would make reading code so much easier. Exactly like the browser tabs, vscode shouldn't jump between tabs when you go back and forth.
I also think clicking a name in vscode should go to the definition/declaration of that name in the same tab, unless one clicks "open in new tab" (which does not exist now, but it would be great too).
Basically, IMO, if tabs and navigation behaviour of vscode was exactly the same as that of browsers, that would be the least frustrating and the most intuitive, since everybody knows how to use browser tabs.
This issue makes me mad every time i go back with more than one tab open, @kieferrm can this be added to the next months Iteration Plan?
I also think clicking a name in vscode should go to the definition/declaration of that name in the same tab, unless one clicks "open in new tab" (which does not exist now, but it would be great too).
That would make "go to declaration" close the current file though, which I would not want.
That would make "go to declaration" close the current file though, which I would not want.
I'm also okay with a config option like "editor.openDeclarationsInNewTab" which is true by default, so it behaves like you want, but I can override if I need to.
I often have two editors group opening the same file, and navigating from the second one would result in cursor jumping to the first one. Which is really disturbing.
Most helpful comment
I would like to add that this feature request might well be what most users expect. After all, VS Code is a tabbed view just like a browser is. When I hit "back" and "forward" in a browser I don't expect it to switch tabs either.
I guess you get the least surprising behavior by adding new commands
workbench.action.navigateBackInCurrentEditorrespworkbench.action.navigateForwardInCurrentEditor(not sure whethereditoris the appropriate domain concept for "tab"). These could behave just like the existing actions, except they skip all the elements in the back-forward history that aren't in the current editor. This way you keep a single global multi-tab back-forward history which can be linearly understood.