Proper tabs for open files

[TurkeyMan]

I really miss proper tabs for open files (like VS proper), and the ability to rip a tab out into its own window.

[inakianduaga]

+1

Would it be possible to add tabs through a custom extension? I quickly looked at the docs but didn't seem possible to add that type of functionality with the current API

[bpasero]

Would it be possible to add tabs through a custom extension?

No, this is currently not possible from an extension (see also http://code.visualstudio.com/docs/extensions/our-approach)

[vasumahesh1]

+1

[snehilmodani]

:+1:

[Xety]

:+1:

[Nicte]

+1

Tabs are the default way to work even in Visual Studio, to not mention other text editors such as sublime.

[bpasero]

For those that are missing tabs, have you tried using Ctrl+Tab to navigate in the history of opened files?

[snehilmodani]

Yes. But the file remains in the Ctrl+tab context even after closing the file. The experience is not the same as that of Sublime / Atom.

[bpasero]

@snehilmodani right, would it help if the list was showing only what you have in the working files section of the explorer? can you work with the working files list at least?

[snehilmodani]

That would be great!

On a side note: Isn't a layout with file names as tabs more user friendly. It is extensible to having one or more sections of tabs each with their own set of opened files. (Again i am taking Sublime Text as reference here)

[bpasero]

I think having tabs or not is independent from having sections. Today you can open up to 3 editors side by side in VS Code and thus we do have sections. Since we do not have tabs, we do not add multiple files into these sections and you can also not have empty sections (which is a separate UX discussion).

Coming back to Ctrl+Tab: We in the team have always worked without tabs from day one and actually we did not even have the working files view for a long time and in fact not so many people in the team are using it. We found that for us it does not matter that much which file you had open or closed. Our minds are rather thinking about the chronological order of which file we edited last. So when I bring up Ctrl+Tab it will typically show me those files I was in last. I am not really looking at the number of files in there, I am only interested in the Top 5 ones at max. The advantage of this model is that you do not have to manage layouts and tabs at all. The management happens naturally while you navigate between files.

We can add a file picker for working files, but it would be interesting to hear if people can be convinced to use Ctrl+Tab as it is today and learn what the issues are.

[inakianduaga]

@bpasero I'll give ctrl+tab a shot, I just realized it can be used for going by to the previous file which is something I wanted and hadn't looked into yet until now. So that's nice.

By the way, regardless of whether one can get by / used to ctrl+tab as an alternative to tabs, new VS code users will probably be put off by the lack of tabs, so if only for marketshare reasons I'd recommend having a tabs option. Every other editor uses tabs (for better or worse), and not having them introduces a rather unnecessary entry barrier to VS code. I'm using VS code regardless of tab support because of its awesome typescript support, but if it wasn't for that I don't know if I would have kept at it the first few times I tried it.

[bpasero]

Yes, Ctrl+Tab is all about navigating back in history of files being worked on. You can press and hold the Ctrl key and press Tab repeated times to go back beyond 1 file.

[snehilmodani]

Ctrl+tab is a wonderful thing to have and I totally am a fan of it. It is something even Atom misses out on.

Regarding Tabs and multiple files in each sections: Even in Sublime Text we can open 3 editors side by side but they still offer a sectional tabbed layout. I agree with you on the clutter and managing the layout of the editor would be quite a task but people are used to that anyways. I would love to be a part of a social experiment where you are trying to convince us to get rid of our cluttered layout based interactions with our editors.

[bpasero]

I agree with you on the clutter and managing the layout of the editor would be quite a task but people are used to that anyways.

Well I am sure we can find more UX examples where we used to be used to something and then we got used to something a lot better :). Think mobile phone keyboard vs smartphone touch interaction.

I would love to be a part of a social experiment where you are trying to convince us to get rid of our cluttered layout based interactions with our editors.

Yes I think we will need to do something like this 2016. @stevencl fyi

[bpasero]

Regarding Tabs and multiple files in each sections: Even in Sublime Text we can open 3 editors side by side but they still offer a sectional tabbed layout.

I agree on an option to allow for more stable sections so that we can have empty sections, but being able to see tabs in this section is just a visual representation of the files in there which in most cases grows so much that you end up not seeing anything. I do not think tabs are a good way to show the list of open files unless you manage these things actively and close them.

[snehilmodani]

I do not think tabs are a good way to show the list of open files unless you manage these things actively and close them.

Some people actually manage them and for others there is close tabs to the right.

[stevencl]

Thanks very much for the feedback.

We have an issue on our UX backlog (#1133) to improve workspace management (managing open files, history etc) which this would be a piece of. Our intention is to improve the experience such that managing the list of open and recent files is straightforward and easy and allows the user to focus on their code, without having to pay any undue attention to the VS Code UI.

Our hypothesis is that the current system has some rough edges (e.g., closing an editor actually closes the editor, but we think that perhaps it should instead show the file that was previously open in that same editor) and that smoothing out these rough edges will help create a far better experience.

We do UX studies on the product on a very regular basis. In fact, that's how we design a lot of the UX in the product. We iterate over our designs based on real feedback making sure that we use a great understanding of what people do and want to do with the product to inform our designs.

If you would like to participate in these studies in the future (we won't be running any again until mid January at the earliest) let me know and I will add your name to the list.

[snehilmodani]

If you would like to participate in these studies in the future (we won't be running any again until mid January at the earliest) let me know and I will add your name to the list.

Sign me up!

[TurkeyMan]

I do not think tabs are a good way to show the list of open files unless you manage these things actively and close them.

Tab management is an unconscious and uninhibiting part of my development. VS-proper has small discreet tabs, which are unintrusive (vscode already has the filename taking up space where the tab would otherwise be). I do agree that runaway tab spam is a problem, it might be nice to innovate and address this, but I'd say that's lower priority than having tabs at all. VSCode needs to reach a minimum working state. Right now, I find it's getting very close, but I can't quite work productively yet. Starting with established patterns would probably get us working sooner.

It's worth keeping in mind that not everyone is a web developer, I find that patterns and workflow tends to be slightly different for different languages and styles of application. As a native developer, it is common to have a set of associated files visible; cpp+h, perhaps also an inl, and you typically don't work on only one file in isolation. I often have a disassembly view visible next to the code. My editor environment spans 2 monitors, with 4 files visible at any given time, and I would struggle to work in a more restrictive environment than that. I also miss being able to grab a tab and rip it out into a small floating window, which I often set to 'always on top', which is generally used a reference point, or something which I'm doing a lot of copy/pasing to/from.

Right now for example, I'm trying to refactor and simplify some legacy code; my current working set of files is... component.cpp, component.h, component.inl, componentimpl.cpp, componentimpl.h, icomponent.h. That's 6 files! And I can't escape from the occasional tweak of some other files on the periphery. I use ctrl-tab liberally when I'm working on that style of project (flipping between 2 files), but in this context/codebase, I simply can't work without tabs.

Refactoring and maintaining legacy code has a very different workflow from writing new code (which I imagine you guys are doing, and using mostly as a guideline for UX design).

My point here is; there's a modern desire to reinvent everything, and we have seen huge strides in UX design in recent years; vscode already presents some of these, but be careful and apply good judgement when deciding to change the way people have been working for decades. Many established designs are established because they are good and efficient, not because they are old and need updating to be more trendy :)

I would appreciate the opportunity to be part of these focus studies!

[Xety]

My point here is; there's a modern desire to reinvent everything, and we have seen huge strides in UX design in recent years; vscode already presents some of these, but be careful and apply good judgement when deciding to change the way people have been working for decades.

It's the case for me. Actually i can't work without tabs. I'm working with tabs system since years, and without them, i'm really lost. This is one of the reason i'm not using Code actually.

Many established designs are established because they are good and efficient, not because they are old and need updating to be more trendy :)

:+1:

[bpasero]

So far I have not yet heard a good reason for tabs compared to having just a list of "working files" somewhere. Being able to take a file and drag it out into a new window is clearly not a benefit of a tab system, it is a feature which you can have without tabs.

Is it that people really want to open files in tabs, move them around and close them eventually? Is this because you are so used to it or is there actually a value in doing so? Is the value being able to set an active working file set that you later on dismiss to start something new? I wonder what is so good in having tabs that you cannot achieve with another way of representation. And I am not accepting the argument that everyone is used to tabs :). A lot of people are used to saving files and still there are editors with auto save capability and people seem to like it.

[Nicte]

Even if it is not by default, giving the user the choice to activate the tabs feature through some option would be almost as good for me.

For example, what about letting the user move/drag the "working Files" section to the top (converting them into tabs lets say). Again, the user may choose how he wants to work and I think that is great!

[kfranqueiro]

For me it's not so much the appearance of tabs as the behavior of them that I miss. (For example, you can get Sublime Text to look kind of like VS Code in that you can hide the tab bar and show the open files in the sidebar instead...but they still behave exactly like the tabs do.)

The first thing I ever do with VS Code is swap its close file and close active editor keyboard shortcuts, so that ctrl+W actually closes a file when I press it, rather than still leaving it in working files and cluttering up ctrl+tab.

But even then, every time I close a file, I am greeted with a blank screen and have to ctrl+tab just to show the most recent still-open working file (heck, when it's the last one, I seem to also need to hit enter after ctrl+tab; not sure what that's about). In any other editor, I'd immediately be greeted by either the most recent or adjacent open file (tab) upon closing the current one.

Additionally, ctrl+tab between working files appears to work in most-recent order, as opposed to tabs which usually operate in the order they appear or are arranged. (I've seen some editors support both.)

I don't use split windows, so if any of these behavioral differences have anything to do with that, it's lost on me. Maybe I'd understand it better if I understood it from that angle, but wouldn't no-split still be the most common use case?

At any rate, it's small but frequent bits of friction like these that keep me away from VS Code and going back to other editors. Yes, you could say it's that VS Code operates differently from what I'm used to. But when what I'm used to works, and VS Code operating differently causes friction that I'd sooner use a different editor to avoid having to deal with, it's kind of a big deal.

[bpasero]

Yes, I can see a model where the editor area behaves similar to tabs without showing tabs. We want to explore this next year.

Btw there is an extension that - once you close an editor - opens the next one from working files. If you combine that with changing the keybinding as @kfranqueiro suggests, you get pretty close imho.

[bpasero]

Here is the link: https://marketplace.visualstudio.com/items/bigous.file-smart-reopener-vscode

[TurkeyMan]

So far I have not yet heard a good reason for tabs compared to having just a list of "working files" somewhere. Being able to take a file and drag it out into a new window is clearly not a benefit of a tab system, it is a feature which you can have without tabs.

Sure, it may be possible to do it in a different way... but why? Unless you have some significant improvement or innovation to offer.

Is it that people really want to open files in tabs, move them around and close them eventually?

Yes

Is this because you are so used to it or is there actually a value in doing so?

Partly habit, but also because nobody has presented anything significantly superior yet. Innovation should present a significant advantage if it's going to insist that people fight and retrain against their decades old habits.

Is the value being able to set an active working file set that you later on dismiss to start something new?

I'm not quite sure I understand this sentence exactly; are you trying to describe an alternative where you work on terms of multiple 'working file' sets? Difficult to imagine. I'm not sure that would be universally useful. For legacy, maintenance, and re-factor tasks, I think it would be a severe disadvantage to work this way, since your working set is usually not known in advance, rather, it's emergent as you work. The traditional model already works fine in these workflows.

I wonder what is so good in having tabs that you cannot achieve with another way of representation.

From a different perspective; consider space utilisation. There already is a tab at the top of the code window, it's where the filename is, it just doesn't have the tab rectangle around the name (it even behaves like a tab; if you middle-click, it closes!). To the right of the filename above the code window is currently empty wasted space (where tabs should be). At the top left of the workspace is the 'working files' list; this is doubly wasted space since it just doesn't need to exist, it's space could be moved to the gap where tabs usually are, filling in that wasted space.

I also find a further practical difference than space utilisation and habitual tendency; I like to have the tabs associated with the editor window that they are bound to. I usually have at least 2, 3, often 4 code windows open (in vs-proper), and each has a couple of associated tabs. Perhaps in one window I have widget.cpp/.h, and in the other I have gizmo.cpp/.h/.inl. These tabs are logically associated with the code window they are attached to, and I find that pleasing.

And I am not accepting the argument that everyone is used to tabs :). A lot of people are used to saving files and still there are editors with auto save capability and people seem to like it.

Well, accept it or not, people find it to be a reasonable and strong argument. But I'll reserve my judgement if you have something significantly better in mind. By all means, if you think you can meaningfully improve on tabs, give it a shot, but don't stubbornly force it through on account of 'trendy' innovation alone ;) .. It needs to be substantially superior to eject the status quot.

I can only say that the current 'working files' list is definitely not superior. It basically is tabs, just arranged vertically, except with the disadvantages that the tabs are detached from the editor window they're bound, and the list is living in wasted space while the usual location for tabs is empty. I also don't like that the 'working files' list has a dynamic height, which means the project tree moves around vertically, and I suspect I would like it even less if the 'working files' had a fixed height and vertical scroll bar instead.

It's just not superior to regular tabs, and therefore offers no compelling reason to adapt... in my opinion :)

[Nicte]

+1 @TurkeyMan

[bpasero]

In the VS Code team, we have been working without tabs and without working files since the beginning (4 years) and we are not missing anything. So, personally I do agree that the working files section is wasted space and I keep that section collapsed. However, we also work with auto save enabled and usually do not care about dirty files. Working files was introduced primarily to give dirty and untitled files a place to show up. Later on we decided that it was also a useful place to help people that are missing traditional tabs because it is a similar representation, just in another UI way.

We do reserve space above the editor to show file information and actions. One could argue this space is the same space needed for tabs. But my argument against tabs is, that typically the horizontal space is not enough to show the list of working files because you quickly end up with this:

This is the nightmare we try to prevent: You need to scroll left and right through the list of tabs to find the files you want. Tabs only work good as long as you do not have more tabs open than can be displayed horizontally. Once a tab gets small enough so that the file name is hidden, you need to start closing other tabs only to see what is going on.

Now, obviously working files has a similar problem, just in another dimension. That is why we in the team typically just use Ctrl+Tab for everything and don't care about what is opened or not.

To summarize: working files is not our answer to replace tabs, it is rather the combination of working files and Ctrl+Tab. And our team is more or less 100% on just using Ctrl+Tab and nothing else.

[TurkeyMan]

Your image appears to be unnecessarily exaggerating the issue; unrealistically narrow window, diagonal tab edges, way too much text in the tab, dot on the right ;) vs-proper nails the tabs beautifully, and there's no reason not to roll with small discreet tabs as it does.

I'm a very liberal Ctrl-Tab user when it's applicable, but you can't use Ctrl-Tab unless you're actively editing no more than 2 or 3 files. I have a suspicion that your opinion on this matter may be quite biased towards your particular project, and that might include a language bias. In C/C++ the typical number of working files is doubled or tripled when you accept there is a .h, and in my case, often a .inl complementing every .cpp. Ctrl-Tab is less effective in this scenario, and you tend to use Ctrl-~ instead (toggle cpp/h; which I have also posted a feature request for), in conjunction with tab management. Or consider Java, where every class - no matter how small - is required to live in its own file.

In my current day-to-day I often have a working set of 10s of files, Ctrl-Tab is no use to me when I'm working this way. The most practical workflow is 2-4 editor windows, and a couple of tabs per window. I didn't choose this layout because because I love it; it simply emerged, because it's the most efficient workspace layout for this particular job.

[mikewl]

+ 1 I usually have the editor split and closing a tab is a bit more intuitive than having 10+ working files.

I also usually am only working on a subset of files and like to keep those handy. 5/5 is easier to manage than a list of 10 for me personally. I am also actively moving between them continuously. Tabs also do help in that there is a visual indication that you have too much open - the 'tab hell' shown by @bpasero.

I do accept that tabs aren't necessarily the holy grail of window management. However, for languages or projects where multiple sets of files are to be worked on, tabs would be less effort to manage.

A simple example would be .cpp and '.h' with tabs it would be two clicks both focused on top of the window whereas with working files it would be 3-4 clicks with working files which require you to select the editor in question and then select the new file to edit.

Tabs and custom tabs would also allow for some interesting extensions to be added easier. An example is a console or a plot tab. These would either require special entries in the file selector section or would have to be discarded on close with the current system. I very regularly come back to my plots so closing the window would then require it to be re-plotted. Or the console would be closed and the data inside lost.

However, if a suitable alternative is available then I would be happy to test it. I just feel the horizontal real estate on current screens is larger than the vertical real estate which the current window management design does not take advantage of. Though I would dislike it if tabs were larger vertically than the current names in each window.

[ianwesterfield]

I'm curious why there's so much pushback on implementing tabs. Technically it isn't difficult and there's already working files implemented; why not both and let the users decide?

This sounds almost like spaces v. tabs, 2.0

[inakianduaga]

I'm curious why there's so much pushback on implementing tabs. Technically it isn't difficult and there's already working files implemented; why not both and let the users decide?

This sounds almost like spaces v. tabs, 2.0

Completely agree, it's probably way easier to push the feature as an option (default off if it makes the anti-tab people happy), and track usage through stats/feedback than theorize endlessly as to whether it makes sense or not.

[stevencl]

I realise it seems as if we have been theorizing endlessly over this instead of actually doing something and apologise for that. However, we do have an item to address this on our backlog (referenced above - #1133). We just haven't been able to spend a significant amount of time on this recently as we have been working hard on localisation and accessibility.

As I mentioned above, we are aware of the issues with the current experience for managing files and have a number of changes that we want to make to improve the experience.

One of our goals with VS Code is that as we make changes to the UI and the UX we ensure that VS Code remains a lightweight, powerful editor that allows users to focus on their code. One of the ways we try to achieve this is through being very careful about any new UI we add to the product.

Our concern with adding tabs is that it introduces another set of problems that end up requiring the user to focus on the UI instead of the code. Our experience with Visual Studio for example has shown us that many users often end up with many tabs open containing files that they no longer need and that end up cluttering their workspace. This causes some issues when users are looking for files and other code assets. To solve those issues more UI is needed that allows people to close all tabs, close all tabs except this tab, tab overflow controls etc etc. We want to avoid this situation and hope that the designs we are working on will help us achieve this.

This isn't an ideological debate - we truly are trying to maintain the minimal aesthetic that we believe provides a lightweight, powerful experience. We are simply being very careful about introducing new UI and UX into the product.

It's entirely possible that after a few rounds of design and research on this that we end up introducing tabs. But we would only do so in the knowledge that this is the best way to improve the way that users manage the files and assets they work with, but does not end up cluttering the UI.

I hope this helps explain our view on this. And I apologise again for making it look like we are navel gazing and not doing anything about this.

[kfranqueiro]

Thanks @stevencl, it's good that it's at least on the radar and there's some brainstorming going on.

Our concern with adding tabs is that it introduces another set of problems that end up requiring the user to focus on the UI instead of the code.

I feel like I need to focus on the UI instead of the code right now though, so this argument cuts both ways. :)

many users often end up with many tabs open containing files that they no longer need

It's interesting that you say this, since I sort of got the impression that part of the point of working files was to encourage keeping more files open at once. What you describe here is apt to happen with working files too, at least with the default keybindings (and is why I played with switching the keybindings for closing the active editor and closing the working file completely).

When it comes down to it, if VS managed to optionally replicate the behavior of tabs (which it seems like at least one of the things in #1133 relates to) while still keeping it on the side instead, that might be a good enough start. Ctrl+tab order being MRU vs. order-of-appearance is another thing (Sublime allows both via different bindable commands).

[ianwesterfield]

@stevencl, thanks for your response. I would like to comment on some of your points:

[...] we are aware of the issues with the current experience for managing files and have a number of changes that we want to make to improve the experience.

I'm certainly looking forward to what seems to be a very bright future for VS Code. I was excited when I heard Microsoft was bringing such a powerful IDE as Visual Studio to worlds beyond Windows, and for embracing new paradigms of app development with Electron. Kudos for your work to date!

One of our goals with VS Code is that as we make changes to the UI and the UX we ensure that VS Code remains a lightweight, powerful editor that allows users to focus on their code.

I don't think anyone can bring a convincing argument for tabs making interfaces weak, sluggish or distracting. In fact, there is far more horizontal space for tabs than there is vertical space above the project tree view. Having the working files live there, to me, makes the left of the window look far more cluttered than it has to be.

Our concern with adding tabs is that it introduces another set of problems that end up requiring the user to focus on the UI instead of the code.

Would there be any reason to use anything beyond TextEdit or Notepad if it were all about focus on the code? Stipulating that functionality, for all intents and purposes, is the same across most editors, the UI/X used to reach that functionality and the quality thereof is really where a product sets itself apart.

Our experience with Visual Studio for example has shown us that many users often end up with many tabs open containing files that they no longer need and that end up cluttering their workspace. This causes some issues when users are looking for files and other code assets.

Here is an argument that I don't think matters for or against tabs or a working files list; when working with more than one file, you will always have to break your focus to look for code assets.

Even so, the working files list still doesn't solve the problem. Too many working files causes the list to scroll and the list can't be expanded. So in stead of eventually scrolling tabs, you more quickly going to be scrolling down the working files list.

[...] we truly are trying to maintain the minimal aesthetic that we believe provides a lightweight, powerful experience. We are simply being very careful about introducing new UI and UX into the product.

I can appreciate and support this stance to a degree. When the community raises it's voice, you must start talking about user adoption. Isn't that why you placed VS Code's lack of folding as a user adoption concern in your roadmap for March? Some things are just the way they are and for good reason. The Start Menu on Windows and the dock on OSX comes to mind.

[...] I apologise again for making it look like we are navel gazing and not doing anything about this.

That's definitely not my take on it, so no worries there. For reasons I already stated, a healthy conversation about this can certainly only enhance the greater purpose that is the UI/X of VS Code.

[mikewl]

I also want to chime in and just say that I think that I don't feel "navel gazing" is happening at all. The timing of this issue is partially at fault - November 19 doesn't give time to put it anywhere in December and possibly January depending on how far things are planned ahead. Also - this conversation that has started again is more important than just randomly implementing tabs because the users want it.

I do have to agree with ianwesterfield in that the working files interface isn't ideal and that there is more horizontal space than vertical space. Massive file lists and many files being switched between are vscode's current weaknesses in terms of managing working files. When you start hopping around 16 different files then being able to manage which split editor they belong to is something working files would be hard to beat tabs in. That being said, splitting the working files list into two different sections would be a reasonable solution.

However, stevencl made an argument that makes me very happy. "It's entirely possible that after a few rounds of design and research on this that we end up introducing tabs. But we would only do so in the knowledge that this is the best way to improve the way that users manage the files and assets they work with, but does not end up cluttering the UI." By actually trying new things can improvements come.

An easier way to manage the split windows would already be an improvement. I can make an argument for working files in that managing the windows can ALWAYS be in the same location. Managing tabs is more effort when you want to rearrange 2-4 splits (high resolution screen + atom = horizontal and vertical split when needed). So there is a possible solution that keeps the working files interface but rather extends it to be a bit more complex.

[stevencl]

Thanks, I appreciate the opportunity to have this conversation.

@ianwesterfield, you're right about the working files and have highlighted one of the issues that we want to address. There are other issues too, many of which @kfranqueiro has highlighted. The current experience is definitely not the desired experience.

Having worked on the design of Visual Studio for a number of years though I have seen the UX problems that tabs can cause. I spent 18 months working on the preview tab experience in Visual Studio which is an attempt to reduce the 'tab hell' problem that @bpasero describes above.

We want to try to avoid getting into the position where this becomes necessary though. So we want to continue on our design deep dive to discover the options that are available to us and then settle on one. As I said earlier, it might well be that we end up with tabs. If we do, we will know that is the best approach we could create that will provide a great experience for managing files and other code assets.

Thanks for all the insights and descriptions of the issues you are currently having with how we manage files in VS Code.

[ianwesterfield]

@stevencl, It's funny you should mention the preview tab - I love it. It's great how VS Code, Sublime, Atom, Brackets (via extension), etc. have a preview feature like this by default.

I'm very happy Microsoft has given us the opportunity to participate in ongoing design discussions by keeping this project open. If the users only had that voice during the redesign of the Start Menu, Windows might not have needed another release cycle to finally get massive on-boarding post Windows 7.

[TurkeyMan]

It's entirely possible that after a few rounds of design and research on this that we end up introducing tabs. But we would only do so in the knowledge that this is the best way to improve the way that users manage the files and assets they work with, but does not end up cluttering the UI.

Since I opened this issue, which seems to have resurfaced, I'll just like to add that I think this comment is quite satisfactory. I rather suspect tabs will appear, but I completely support exploring new ideas, and code is a great platform to do this. I love the work you guys have done so far. That said, just keep in mind that we do want to use this, and the sooner I can use it as my primary editor the better, so I for one would appreciate if you could give us a familiar (still light-weight) experience that we can use productively and feel at-home in right now, and we can get on with our work. Then you can take all the time in the world to explore new horizons :) It's just that we're eagerly awaiting code to reach the magic line where we can adopt it full-time. For me, tabs are my only usability complaint, native compiling and debugging is my only technical one.

I don't think I'm the only tired and suffering windows user who's hopelessly addicted to visual studio. Salvation is just a couple of small issues and features beyond our grasp, it's progressing quickly, and I'm grateful for the opportunity to participate and watch with such visibility.

Sadly, Windows remains the worst dev platform/ecosystem, with a the best dev environment, and it's been that way for like, 15 years. Really weird. I don't know why, but it seems that for me, dev environment (productivity) trumps ecosystem in my balance, but it's a painful balance and I'll be as happy as a pig in mud when I can use VS in linux full-time! We're so close! I know you guys see this as a vehicle to explore new territory, and that's totally cool, but in the short term, we really just want VS on linux, (or osx, if you swing that way), as we have dreamed for a decade or so, and we can finally, after all these years, end our suffering! ;) </dramatic_commentary>

TL;DR, exploring is totally great and I'm confident you're committed to the best end-product you can make, but safe familiar solutions in the meantime perhaps?

[lordgreg]

+1 for tabs. The question- why don't you remove it from Visual Studio Bundle then? See what happens then...

[launchpadinteractive]

+1 for tabs! Please implement this in a future update.

[peterbourgon]

The running assumption appears to be that "[tabs] in most cases grows so much that you end up not seeing anything". I would like to challenge this assumption. I use tabs as a visible index of the files I'm currently interested in, and I actively manage that index as my interest shifts over time. Visibility is important: I refer to the physical tabs constantly to reorient myself. With Working Files, I'm stripped of my ability to view and manipulate that index. For example, there doesn't appear to be a way to remove a file from Working Files via the keyboard. It feels like I'm fighting the editor. Please add Sublime Text-style tabs.

[DanWahlin]

While I agree VS Code works fine without tabs now (been using it since the beginning quite productively), I also agree with some comments above that suggest having tabs as an option (maybe disabled by default) and letting users decide if they want them or not.

Everyone is different so having an option there would be great. Even though I can work fine without them, I wouldn't mind having them added in and would probably use them some - too many years of using VS full. Sounds like they're already on the backlog though - thanks!

[korzio]

+1 for tabs. Almost 1 year work with VSCode and I like it a lot. But still miss tabs, especially when working with debug or search, or git left section. Tabs help not to think about which file contains code, you have been working before. I believe users manage tabs and their order to keep in mind also a position of tab, which can be associated with source code they are working. Splitted editor tabs also can keep this intention.

Ctrl + tab is a key action, and tabs is visual action, which is Much Faster.

[Growiel]

I could probably live without tabs... if VS wasn't so bad at managing "working files". I very often open files just to refer to the inside them, without actually editing them, but VS doesn't place those files in my working files list, whereas I would definitely have a tab open in a tabed environment.

This combined with the fact that when you close a file / focus a new "working" one, the file explorer MOVES to the open file instead of staying on your last location make for a very confusing experience.

I understand that those are not concerns for you since "you've used it without tabs for 4 years", so anything that goes outside of the Ctrl+Tab scope is seen as a weird way of using the program.

[jayrosen1576]

This needs to be a feature and whether it is on or off by default is irrelevant. Virtually every text editor / IDE uses tabs for navigation. Maybe some feel that there is a better way but for most of us tabs are efficient, easy to use and familiar... and obviously we love them! Take them out of Visual Studio for one release to see how important they are... (cue Metro-style epic developer meltdown) Please consider tabs for a near term release. it's the only thing holding many of us back from full time adoption of VSCode.

[alvarod-infocorp]

:+1:

[MadSpindel]

I am much more productive with tabs! I use Atom as I use Google Chrome (Ctrl+1 for first tab, Ctrl+5 etc. Ctrl+Tab, Ctrl+Shift+tab).

Working files makes me less productive and I always feel a bit frustrated after using it.

So please, implement tabs.

[isvforall]

Tabs will be very useful, +1