It seems like this might have already been somewhat implemented by @mkcode in #134525 over 2 years ago. Is there any reason why this hasn't been merged and is there anything I can do to help get it merged?

I'll chime in again just to share my experience and perspective with all this:

I completely understand microsoft's values in making vscode as accessible as possible. And, vscode is so close to be able to make people that prefer keyboard oriented approaches (usually coming from vim or eMacs) happy as well. It's just one or two "opt-in" settings away, meaning there would be no changes to the out of the box user experience.

Ultimately, I was unable to create a consistent keyboard oriented workflow in vscode, and have therefore been using neovim. A lost user that could have been supported, by allowing an opt-in setting change to unlock keyboard oriented workflows.

+1

@jonathanjameswatson interesting that it doesn't seem that difficult to implement. #134525 is pretty close, I'd just want it to move the tab into current tab group from quick open (not open again).

Hmmm, I've never hacked on VS Code, but given that the other PR is 20 lines and I think there could be a compelling 2 minute video "how to setup VS Code like Neovim or Emacs" it could be pretty compelling and I don't see why it wouldn't be merged.

I think it makes sense to move the editor to the current tab group rather than re-open it – with re-opening, if you only use quick open, then you could presumably end up with all editors being in all tab groups.

I believe complexity may come from the interaction between revealIfOpen and moveToCurrentTabGroupIfOpen. It would not be an unreasonable to assume that moveToCurrentTabGroupIfOpen would not require revealIfOpen to be set, but if this was the case then it would not be clear what would happen if both were set. Perhaps we could use a name like moveToCurrentTabGroupOnOpenReveal instead? Although, perhaps that is too verbose.

I have made a PR that implements this feature: #205442

Demo here:

@jonathanjameswatson Amazing!!! It works just like I imagined.

This will really help users coming from Emacs or vi. Users of those editors are accustomed to splitting windows into "frames" or "panes", then being able to recall any buffer into any frame without the file being opened a 2nd time. Your PR and revealIfOpenInActiveGroup makes that possible in VS Code. Without this, users must open a file once-per-Editor Group which creates a mess and kills the "fast switching". This is especially confusing for users who want to do side-by-side editing with tabs turned off.

I wrote these docs that I think should go under the "Working without Tabs" section, but I don't see how to edit the docs in the vscode repo.

Docs: #205442 (review)

@mkcode Can you review the PR and docs in my approval as well? Thank you!

Docs PR: microsoft/vscode-docs#7043

This would be great!

🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

@bpasero @benibenj This feature has been implemented (PR) and documented (PR).

Who can me and @jonathanjameswatson work with to get the PR merged? This is my first time contributing to VS Code and it's been a good experience so far!

@benibenj Is there any way to bump this?

The feature is implemented, works great, is documented, is under an option, and has the votes required.

It seems like it's just stuck in VS Codes "backlog" process. This feature will help users switch from vim/neovim/Emacs and other buffer-based editors to VS Code.

Pinging @loganrosen as the change is part of the Editor Resolver Service

I think you meant @lramos15 🙂

Exactly, I meant @lramos15, sorry 😅

Bump!

bump