Vscode: Proper tabs for open files

+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

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)

+1

:+1:

:+1:

+1

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

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

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.

@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?

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)

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.

@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.

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.

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.

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

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.

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.

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.

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!

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!

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:

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.

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!

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.

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.

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

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 :)

+1 @TurkeyMan

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.

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.

+ 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.

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

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.

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.

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).

@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.

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.

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.

@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.

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?

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

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

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.

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!

+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.

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.

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.

:+1:

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.

Tabs will be very useful, +1

:+1:

@MadSpindel "Working files makes me less productive and I always feel a bit frustrated after using it." 1000% agree... it's like we're being forced into no tabs for someone to make a point or something. We don't like it, if you do, then make it optional for us please.

Visual Studio Power Tools has an option to display tabs vertically, which I absolutely love.

:+1: and I agree with @sitefinitysteve. If the team insists on not having tabs, then at least improve the extension API so it could be added by a third party.

Here is where tabs are important- we have to step back a moment to another missing feature:

VSCode needs to dump the non-informational implementation of Working Files, and then add the feature to allow opening multiple projects. I do my work by separating my client side code into one project and my server side code into another project. On a large screen I want two coding windows open, with one project tree on the far left. Client code on the left window, server code on the right window. Now, within either project I will be working on multiple source files. In those cases I want to reference them as tabs above the respective project window they were opened in. I may have 3 or 4 tabs on the client side project and 3 or more tabs on the server side project.

The organization is organic. The whole tree of work, multiple projects, is displayed on the left. I have project separation by code windows and I also have open source files being worked on, or referenced, by tabs above their respective project windows.

This is essential workflow for me. I am currently doing exactly this in Atom but I like VSCode and would like to see that flow replicated in VSCode. To do so VSCode needs to implement multiple project support and tabs above respective windows. Otherwise it is just another a little guy's editor, and I don't believe that. Please.

@riclf has it spot on.

I usually have 3 vertical columns open, HTML, JS and CSS from left to right.

In Sublime I had all my html tabs above the first column, all JS files as tabs above the second column etc. The tabs have a context and I know I'm not going to be opening the wrong file in the wrong column.

This is almost impossible in VS Code, I can have 3 columns open only by using "open to the side" twice, and a column can disappear totally if a file is closed, at which point I can open a new one but have to reorder them. If I open a file it re-opens in the column that the cursor is currently in, so if I open a css file I have to make sure my cursor is in the third column. It is absolutely infuriating.

Not to mention that the Working files section takes a way vertical space in my folder tree, which is a real problem on my laptop.

A question for the microsoft team. If you have a split view, how are you supposed to know which column a file in "working files" is associated with? It's simple when the tabs are above their respective columns.

Just my 2c.

I had zero cognitive discomfort getting used to Working Files. I love them much more than tabs. VSCode's UI is on the right track. I'm not against opt-in tabs, but would throw a fit at opt-out tabs.

Working Files are tabs in a better layout (more scroll space). They are missing "tear off" and drag features, which can be added in the future.

As a mvim user, I have multiple sets of TDD files open, and tab between them. For instance, I angular + tests, server + tests, cucumber or behave + scripts. I don't want to tab to access a single file, but a combination of open files. I switched to VSCode for 3 months for a Typescript project, because it really had best-in-class / amazing Typescript support. However, as soon as I moved to a non-Typescript project, I found I compared its general purpose search, navigation and substitution capabilities directly to mvim and am sorry to say I rapidly (i.e., instantly) reverted to my former editor. I have a 27" Apple Cinema display and would get a larger display if possible. I have plenty of room for plenty of tabs and and file-pairs, and don't have a compelling reason to be limited in using that space by my editor. I don't want to deal with just one file at a time - I want to open many, and to track the flow from tab to tab.

I gave Visual Studio Code another try two weeks ago. I was actually pleasantly surprised when just mucking about with a few files. But when I started working on an actual (large) project with more than a handful of files opened, the lack of tabs became very annoying. _Working Files_ just didn't suit me and it slowed me down. After 3 days I was so annoyed with it that I went back to Sublime Text. I have two 24" screens at work (Windows), a 27" Mac at home and can easily have 20 tabs open and still distinguish which file is which. Plenty of screen real estate for tabs in my case. _You_ are already showing the file name of the file that is opened in the editor. All the space to the right of the file name is unused (except for the icons to the right of the window) and could be filled with tabs (which is what Sublime Text does too). I say give users the option to work with _Working Files_ and/or file tabs. For now, I am switching back to a combo of Sublime Text and Visual Studio Enterprise. When tabs are added I will reconsider.

For Working Files option, I have to toggle side bar (as I keep it hidden for expanded view of code) to select file. And the Ctrl+P and Ctrl+tab options also not user friendly.

I know you guys are trying something different for that, but the options you already provided not user friendly. Sorry.

please provide an extension for this, so users have a chance to use tabs instead of being force to use the working list. I very hate the working files feature, it causes me switch files slowly and stole my productivity

When I was new to VS Code I really missed tabs. Then I discovered ctrl + tab and I no longer need them.

I've been trying to make vscode (which is awesome in most parts) my primary editor for several months, but the lack of tabs keeps annoying me and hurting my productivity (I'm one of those who actively manage the set of open tabs in other editors). Ctrl+tab is not a replacement for tabs.

It's obvious that the vscode team is biased against this, and currently aims to "convince" users that they don't really need tabs. But this is the same type of thinking that lead to the removal of the Start menu from Windows 8 (we all know how this ended).

@pesho Exactly!

Now that code folding is out this is the top issue in User Voice. We are weighing a number of options internally as we continue to weigh community feedback, user experience testing, etc. Thank you all for the discussion here. Very helpful.

probably its the only reason why I opened for the first time vscode almost a year ago and closed it right after few minutes play. and you still do not have tabs. Hope it will appear soon, so I can use it. Its Open source, and people from Microsoft need to change their minds (thats what they are tring to do now, isnt it?) and listen to community, not simply "we are using this tool internally and we dont need tabs bla bla"

@pleerock You not even going to try an IDE because it doesnt have tabs ?! (O.o) weeeweweweweeeww . They dont want to add tabs because tabs are pointless , verbose they generally add no value while adding top wieght on the windows chromes space. The alternatives provide more metadata, ease of use and quicker navigation.

With tabs I choose which files remain open. Whether it's CTRL+tab or "Working files", if I open a file to look up some code into it, switch to another one to use said code, I have no ways of going back to my first file short of having to re-navigate to the file in the explorer.

I know I have 3 editors, but sometimes I don't want to override the other 2 with my look-up code-only file.

If when I open a file it stays in the different file histories, then I'm fine without tab. Maybe if a file has been open more than 5s it deserve an entry in CTRL+Tab.

@4tron yes it is for me, because I want to use IDE which is convenient to me. for someone loosing tabs is pointless and safe their space (probably they are using netbooks and don't have enough space for really few extra pixels =)), for others its convenient and increase their productivity. Any good software should be customizable and have ability to hide/show panels. "save a space" is not argue. Introduce tabs + add ability to show/hide them (if its really needed for someone=)) they best way to go. No need to open a new America or go with wrong innovations, need to learn from best IDEs here which made UX for years better and better, like intellij, visual studio and others

It's really simple- just make it a Preference- tabs or no tabs. When tabs are on, no Working Files, when Tabs are off, Working Files. That was Genius ! ;)

Me, I'm a tabs guy. I find Working Files very limited and non intuitive, as well as taking up vertical space on the Project Tree. But it hardly matters if we can't have more than 1 Project open. :(

I think a preference should be fine too.

I also minded a way to enhance working files system. You should use tab line as historic.
For exemple, if you open 4 files in left window, and then open a fifth making the oldest modified file out of the tab line, it should vanish and return as only "modified file" in working files.

You could also make it smart, the system could also prioritize vanishing first saved and so unmodified files.

The fact is that tabs are sooo practical, even if tabs bloating is a problem. You should think about a way to use tabs but limiting the number of them.

Usually i keep open tabs that i haven't edited for days. this is generally that who make it bloating.

+1

I have a 4K screen and having no tabs to horizontally is really turning me off from VsCode

BTW, I want to clarify that I don't just want tabs, I would like sets of tabs. As a full stack mvim TDD developer on the Mac, I think in terms of contexts. html + css, angular + tests, node + tests, cucumber + test steps. I normally work in a single context for a few lines of code before moving to the next context, TDD style. When using mvim, I not only switch between these contexts very quickly (using the same key sequence that I use for Mac Terminal, Mac Finder and Safari or Chrome), but I benefit from macros that automatically open the paired file, so that from an angular source file, I can automatically open the corresponding test. This is an incredibly productive way to work, and keeps my fingers on the keyboard.

If I found an IDE that would allow me to open "associated" files in frames next to each other, just by switching one tab, e.g. when I open button.html it would open button.js next to it and button.scss in the third frame, I would never use another IDE ever again.

I know it will never happen, but just sayin'.

Well, then, you should be using mvim! http://www.vim.org/scripts/script.php?script_id=1567 Command :AV opens associated files (A for associated).

What @jtosey talks about is exactly what I came here to say. I use panes to organize a set of related files. Most tab management involves getting those related files next to each other when I switch contexts.

+1

Same here, would love tabs.

I've just switched over to VSCode from Atom and noticed how amazingly organized and clean it feels after working with it for a while. The reason? No over-population of tabs! The actual lack of tabs is what makes this experience so smooth. My primary file navigation is the command-P menu that allows me to quick jump to any file.

VS tabs are perfect, please bring tabs, undocking tabs to separate window would be great as well!
Thanks for vscode :)

I'm actually quite curious on whether you want to make VSC as a general purpose file editor, or just a source code editor.

There are couple situations where a tab bar is absolutely demanded.

1. Quickly switch between many tabs.
   A common situation to me is I need to compare 2 or more files by its shape, such as to compare between simplified Chinese and its traditional equivalent. A diff won't solve the problem because they are different characters. The only way is to quickly switch between the tabs to see if there's any missing word by your eyeballs. Using ST and I can switch tabs using Alt-NUM, but in VSC the only possible way is to use multiple Ctrl-Tab, or mouse rapidly moving and clicking.
2. Long and hard-to-type file names.
   Using Ctrl-P to switch between files is not bad. But how about some file names that share a long common fix? How about some names that are not in English? Consider how much time would you spend on Ctrl-P to switch between 青年急着买房的原因（上）.md and 青年急着买房的原因（下）.md?

I'd say, neither of the situation will you hit when writing code, but as a general purpose editor, this is a serious issue.

@msg7086 Im not sure about point one but for point two could you not ctrl + p and then type .md leaving you with the two options and then just ctrl + tab to choose the one you want? Not sure i am understand the issue correctly

@4tron Thanks for the reply. However, your method only works if I have only 2 files with that type. In reality people will probably be working with bunch of those files in a single directory. Imaging I'm writing a blog that has 50 posts in markdown format, with different characters in Chinese or Korean or Arabian etc as the file names. The real scenario I was hitting was actually some subtitle files with CJK names, where all of them are *.ass, thus Ctrl+P by extension doesn't work quite well.

Really appreciate if this can be implemented

Developers are used to with it, please make this a priority.

+1 for tabs. Please implement tabs.

+1 for tabs!

I vote for adding tabs too.

+1

+1

+1

We need tabs ASAP.

I miss tabs. I keep reaching for them, would be nice to ref two or three different open documents quickly.

What's the big deal?

• The working files area is locked in height, same problem as too many tabs, except it's fiddly to manage (no mouse or scroll-wheel here). Tabs can be banished easily, giving the user the next document in the open file stack.
• The Explorer column in Code is much wider than Sublimes, sometimes one wants to minimise it when running two apps side by side for space saving (Unity on left, Code on right for example). Tabs don't need any space saving to work, Code already has a nice empty area where they can go.
• Tabs win for ease of use and space saving, no UX research necessary. They are quick to use and we all like them.

Please give us tabbed document management :)

+1, yo.

+1

+1

VSCode is a great editor and has nice integration points with both Git and Nodejs. The main reason that I do not use it as my primary development IDE is because it doesn't support tabs.

Same here. It's the ONE thing which holds me in using it.
Op do 10 mrt. 2016 om 15:18 schreef Konrad Piascik <[email protected]

VSCode is a great editor and has nice integration points with both Git and
Nodejs. The main reason that I do not use it as my primary development IDE
is because it doesn't support tabs.

—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-194867036.

It's a little surprising to see so much push back on this issue given it should be so easy to implement. At the very least make it an option or available through an extension (as Brackets does).

If this does get added, PLEASE add the following:

1. Close functionality like Google Chrome. (Always been annoyed the standard version of VS didn't have this.)
   -- "Close other tabs"
   -- "Close tabs to the right" .
2. An option to open the tab to the right or left. (VS changed the default at some point, but then added an option to change)

Tabs work. They're everywhere, people are used to it. The current list of files is unintuitive. After 2 months using VS Code daily, I still find myself going for a tab almost every time I need to switch files. The fact that every other editor out there will keep using tabs creates a huge barrier for something different becoming intuitive.

In my team, people complain all the time about that, to the point that some people prefer using sublime without any typescript support then using VS Code.

I'm not against UX research to find a "better" way of handling open files, but please don't make this the Office ribbon fiasco all over again, which took half a decade and multiple releases to invent another way to do exactly the same thing.

-1

A few notes for why I'm against tabs:

• Any time spent on tabs will be time taken away from making other improvements to the editor.
• I've been forcing myself to become more of a keyboard commando and not having tabs has been helpful. So I'm arguing from the it's-for-your-own-good perspective even though I'm not even there yet myself.
• Related to the previous, this reminds me of when Gmail came out and I had to convince people that labels were superior to folders. Some people just couldn't process it and are still rocking their AOL / ISP email accounts. I think MS should take a stand here in saying "we just think this is a better way to do things."
• If I would suggest anything, it would be an upfront explanation of why tabs aren't there along with examples of navigating the editor without them.

Well, there is a compromise- Make tabs visible or not in Preferences/Options.

I don't think it takes time away from other improvements because I'm sure they have more than one programmer on this dev. I love being a keyboard commando too. If they were implemented just don't use them but why inhibit those who prefer tabs in their workflow from having them.

Anyway, no biggie. I have moved back to Atom while I wait for VSC to decide what it is going to do. I find tabs essential for the workflow in a large project, along with being able to open more than one Project Folder.

I've been forcing myself to become more of a keyboard commando and not having tabs has been helpful. So I'm arguing from the it's-for-your-own-good perspective even though I'm not even there yet myself.

As I've suggested earlier in this thread, it's the _behavior_ that's missing which is just as important, if not moreso, than the visual component. I'm all for using keyboard shortcuts like ctrl+[shift+]tab or even ctrl+P to navigate to files (including open ones), but the behavior of Working Files and how it manages editor windows (and the fact that it ctrl+tabs in MRU order) I find terribly jarring.

Hold the phone! I got the answer! It's perfect! Ready? We don't _need_ tabs. Let's just extend the working files with a simple option to display them in tabs horizontally across the top of the editor! Woo hoo! Problem solved without creating tabs!

I actually prefer the way it is now - panels for open files and a list-like file picker with "working files" on the side. Back when I used Atom, I hated it that every time I just quickly looked at a file, it would open a new tab, and within minutes my tab bar was full of useless tabs.

So I'm -1 on this. But I would still like to see undocking of windows.

I've just switched over to VSCode from Atom and noticed how amazingly organized and clean it feels after working with it for a while. The reason? No over-population of tabs! The actual lack of tabs is what makes this experience so smooth

this. 100% agree.

I actually prefer the way it is now - panels for open files and a list-like file picker with "working files" on the side. Back when I used Atom, I hated it that every time I just quickly looked at a file, it would open a new tab, and within minutes my tab bar was full of useless tabs.

I get that and that is why we are asking for an _additional_ feature not a replacement for working files. I can't for the life of me understand why both could not be included in the editor. I mean seriously. Look at how many want tabs in this thread! This is not a _Hey I'd like the buttons to be blue_ scenario. This is about a hinderance to the productivity for the vast majority of people wanting tabs in this text editor (which by the way is on it's way to being superior to Atom and Sublime). I get the valid arguments on both sides I just can't understand why tabs and working files can't be included with options to turn of either. Everybody wins then.

@jayrosen1576 Maybe the problem is that nobody really made an in-depth proposal about how it should look like

• should the tab bar sit on top of all windows?
• How would clicking a tab work when you have multiple files open side-by-side, or in a future release, even split horizontally?
• Would the tab of the active file be always highlighted? What if the debug console is focused?
• If you enable the tab setting, would the working files section be removed because it is redundant?
• What about duplicate file names in different folders?
• What about the duplicate close button of a tab and a panel?
• Will closing the panel close the tab?
• Will a tab appear as soon as you open a file like in Atom (urgh) or only when you edit like with working files?

These are all questions the development team would have to spend time on. And as hard as I try, I cannot think of an implmentation that's more elegant than the working files list and isn't confusing.

Here's the proposal for how it should look:

1) Download Atom
2) Open Atom
3) Look at tabs
4) Implement in VSCode

@jayrosen1576 seriously? I named some valid concerns with Atom's implementation and also problems that Atom simply doesn't have because it doesn't have a concept of working files.

Then again, your profile picture says everything.

• should the tab bar sit on top of all windows?
  A: Yes. Try tabs in Atom
• How would clicking a tab work when you have multiple files open side-by-side, or in a future release, even split horizontally?
  A: Tabs appear at the top of each pane. Try tabs in Atom.
• Would the tab of the active file be always highlighted?
  A: Yes. Try tabs in Atom.
• What if the debug console is focused?
  A: Same result as when the debug console is focused now with two files opened side-by-side.
• If you enable the tab setting, would the working files section be removed because it is redundant?
  A: Only if you disable working files (as an option)
• What about duplicate file names in different folders?
  A: Tab includes partial path. Try tabs in Atom.
• What about the duplicate close button of a tab and a panel?
  A: Panel doesn't have a close button. Try tabs in Atom.
• Will closing the panel close the tab?
  A: Yes. Try tabs in Atom.
• Will a tab appear as soon as you open a file like in Atom (urgh) or only when you edit like with working files?
  A: Only if you enable the option to do so (usePreviewTabs = false in Atom turns this off). Otherwise double-click opens them in a tab. Try tabs in Atom.

@felixfbecker Because this product carries the Visual Studio moniker there should be optional tabs, and they should behave as they do in any other Visual Studio product.

It says volumes about your character when you bring up something as piddly as a profile picture in a response to a valid answer to your concerns.

Hold the phone! I got the answer! It's perfect! Ready? We don't need tabs. Let's just extend the working files with a simple option to display them in tabs horizontally across the top of the editor! Woo hoo! Problem solved without creating tabs!

@jayrosen1576 This doesn't actually solve the full problem, since as I've said before (and brought up again in literally the comment immediately preceding yours), it's not just the visual appearance of tabs that's different - it's the behavior. As I said in my first comment here, you can get "tabs in the sidebar" instead in Sublime Text too, but it's still not the same as working files. (IMO it's better.)

@kfranqueiro I totally agree. I was just being snarky. This tab thing is a really silly argument. If VSCode simply had the tab capability of Atom's tabs with the option to hide them (even by default) it would be perfect. I think we are all asking for the same thing. I just can't understand why both cannot be included with an option to turn either off.

Honestly, discussing if tabs are a good choice for a text editor is just stupid. This is not a new concept. Just implement and leave them optional. Make it an extension and let it be the no. 1 extension by far until people realize this is a basic functionality and it makes no sense to not have it, just like VS uppercase menu choice.

@nvivo Couldn't have put it myself. This whole discussion just seems dumb.

just like VS uppercase menu choice.

@nvivo Have you tried this extension? No menu option but you can setup some keyboard shortcuts. works pretty well.

https://marketplace.visualstudio.com/items?itemName=wmaurer.change-case

If you don't like this discussion folks, just move on. Reading this thread is completely optional!

Of course reading it is optional, but it's very existence seems to support the idea that adding tabs in to VS Code is optional and that we should be debating it. A simple poll with the following question.

Will you continue to use VS Code if tabs aren't added soon? Yes/No

Would show that Microsoft would lose a massive proportion of it's potential userbase if they don't add it. Which means that from a commercial point of view, even if they have no need for the feature themselves, it would be commercial suicide for them not to do it. Ergo, this conversation is distracting and unnecessary.

Having said that, we're talking about the same company which still hasn't put extensions into their browser. So I guess anything is possible.

In all seriousness, the only conversation should now be about the best way to implement tabs. There is no longer a question mark over whether people want the feature so let's move the conversation on to something more constructive.

Browser extensions? Activ... NVM.

Honesty i see no reason for tabs. The love for tabs is just too damn up. In terms of getting actual work done shortcuts do everything needed , with search by regex, more metadata and a far better steam lined work process. They provide a basic esoteric need for, i dont know, something familiar. I get the feels like this is just a push to see if ms will serve the community, to see if they really are changing. Although not as pointless as the whole uppercase text in vs issue.

In terms of what was said earlier.

"I don't think it takes time away from other improvements"

Personally i think it does , like for instance creating the ability for extensibility on the text editor window, so that extensions can be made for anyone wanting tabs. I am pretty sure the whole idea of vscode is to keep it as minimal and lightweight as possible, with the end user either adding extensions or extending it.

@4tron, of course there is conspiracy of the evil community to test microsoft here! Isn't there always one?

If tabs made any sense, we would see other editors using them. And if it was a really good way to organize multiple open content, maybe other kinds of software that have this need to organize multiple open content, like say, browsers for instance, would use them too. But of course they don't, because they don't make sense! Can you imagine something people use all the time like browser using tabs? Nonsense!

I say let's play safe. Let's first wait and see if some other good editor supports this new feature so we don't waste time and effort on something that doesn't actually work. Let's check visual studio, intellij, eclipse, atom, sublime, monodevelop, notepad++ or any other one that has a considerable user base. Once at least _some_ of these editors support this feature for a couple years without replacing it for something else, then there will be some indication that this is an useful feature.

But let's not get ahead of ourselves. We need to have something like an issue tracker where people can express that desire directly and maybe let other people vote, so we can really make sure we're not doing this for nothing! We can only take action if it becomes one of the most requested features in the repository. Then we will know that it's not only a trend, but people found it useful for their daily work and want that feature here too.

But until that day, let's wait patiently. Text editors are brand new thing and nobody actually knows what kind of features are needed.

Ghehehe, hilarious!

Op za 12 mrt. 2016 om 11:57 schreef Natan Vivo [email protected]

@4tron https://github.com/4tron, of course there is conspiracy of the
evil community to test microsoft here! Isn't there always one?

If tabs made any sense, we would see other editors using them. And if it
was a really good way to organize multiple open content, maybe other kinds
of software that have this need to organize multiple open content, like
say, browsers for instance, would use them too. But of course they don't,
because they don't make sense! Can you imagine something people use all the
time like browser using tabs? Nonsense!

I say let's play safe. Let's first wait and see if some other good editor
supports this new feature so we don't waste time and effort on something
that doesn't actually work. Let's check visual studio, intellij, eclipse,
atom, sublime, monodevelop, notepad++ or any other one that has a
considerable user base. Once at least _some_ of these editors support
this feature for a couple years without replacing it for something else,
then there will be some indication that this is an useful feature.

But let's not get ahead of ourselves. We need to have something like an
issue tracker where people can express that desire directly and maybe let
other people vote, so we can really make sure we're not doing this for
nothing! We can only take action if it becomes one of the most requested
features in the repository. Then we will know that it's not only a trend,
but people found it useful for their daily work and want that feature here
too.

But until that day, let's wait patiently. Text editors are brand new thing
and nobody actually knows what kind of features are needed.

—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-195715795.

@nvivo Are you really comparing a browser to text editor right now? I understand your overuse of sarcasm here, and it's great. The point i am trying to make is not one of whether tabs are useful or not. I like the idea of a lightwieght / minimal editor. This is just my opinion , I like the idea of the editor being extensible for the user based on their user preferences . That is what i want vscode to be working on. Then we can move this discussion to "Why has no developer created an extension for this yet .. oh maybe i should because i like tabs and i would like that in this , and vscode can do that so yay, now i have a text editor that is similar to my browser"

@4tron It looked to me like he was also comparing text editors to text editors.
I think they're doing a great job at making vscode extensible, but I'm firmly in the camp that considers tabs should be an out-of-the-box feature. This notion "Oh, you like tabs like all the other software you use? Google the problem, find recommendations explaining how to install the appropriate user-contributed extension, and you're good to go!" doesn't fly. I imagine most users just expect tabs exist, and I strongly doubt there are very many people who would think that you'd find a tab bar by installing an extension. I'm pretty sure that's not precedented by any other piece of software ever. Why would people think to do that?

@TurkeyMan
His rhetoric did start with a comparison to browsers.

We are talking about developers here. I do think they would have the initiative if they wanted tabs. I am sorry i am against this idea, but i see no valid reason tabs, I alt + q in vs all the time.I just dont see any value added. this is my personal opinion , and maybe im crap dev for not understanding how tabs are suppose to be useful. I think this conversation is verbose and personally i would like to see vscode being opened as an isolated shell for almost complete customization and even business based models ie. where someone could enhance the customization to a focused degree for say drupal development or wordpress developement where the editors build is based around the ecosystem of the users codebase . That too me seems like a better problem to be solved.

The downside to everything being an extension is you end up with weird undesired interactions between them. In vs code already using GitHistory on top of Smart File Reopener causes weird file closing issues.

Something as basic as tabs should be out-of-box. Now, as others have requested in this thread, opening groups of or creating relations between tabs is where extensions should come into the discussion.

@4tron, It was funny, but I'm dead serious on the point.

External compiler services are something you may decide or not to support in a text editor. Integrated task runners are a nice to have feature.

Tabs are not in this class. Tabs are like windows, buttons and opening and saving files. There is no decision to make here, just have them there and move on, people expect it. This is not an advanced custom thing that few people want to be supported by plugins, they're standard UI in _any OS everywhere_. People are used to it, and there is a reason why every other possible editor didn't require a petition to add them.

And this is why discussing if tabs are good or not is stupid. VS Code is not an UX experiment, it's an attempt to have a good .NET editor for all platforms. Make this damn thing useful for 90% of the people and you will succeed.

I honestly get your point about alternatives, but you just need to understand you're a very small minority. Believing most people asking for this are just trolls that want to test microsoft is just delusional.

That point about it being a call to see if ms would change its stance on tabs , was half hearted, mainly because of the passion for tabs to be included. To the point where someone would not even try the editor because there were no tabs. I struggle to understand this. Lets not forget that it is still in Beta. So hopefully they will add tabs ( as optional please ).

@4tron I tried it many times, and I don't use vscode regularly because it doesn't seem to scale to large projects well, and missing tabs is one of the main practical reasons that seems to be true to me.
I mainly use it as a light text editor when I'm editing a small number of files, but as soon as I want to work on one of our large projects, vscode just doesn't work. Missing tabs, and the fact there's no notion of sub-projects (or 'solutions' as VS puts it) are the only blockers I'm currently aware of.

I just want to comment on this idea of adding everything with plugins though. That's a nice goal; having a great extension framework is important, but I think they need to be cautious about over-committing to that idea.
I use VS, and while it drives me nuts, I find that I'm attached to it because it has a very high level of product quality which is what I expect from an MS product. I've tried every OSS alternative out there (and other proprietary tools), and they all just seem to fall short on the basic usability front (particularly when it comes to debugging experience).
I really hope that the intent of vscode is not to be a light shell that everyone hacks features into randomly via extensions... there are already many other tools which fit that description, I don't find yet another one to be compelling. What I want from vscode is what I've always wished from VS; to be well designed from a usability perspective by professional UX designers, and to be CROSS PLATFORM.

I think those that are against tabs may be missing the point. I (we) do not want an all or nothing solution. All we are asking for is a simple option to turn on tabs (they can be hidden by default) that look and behave like those in the popular Atom editor. If you don't like them you will never even know that they exist. If you do then they can be enabled. And for those that have never used Atom and the multi-pane + tabs experience, I suggest you try it before completely discounting the argument for them. You may not like them, but you have to admit that they _are_ useful for many of us. If not for the excellent node.js debug capability of VS Code I would use Atom exclusively. I don't mind the working files. I think they can be useful, however, they do not make a good replacement for tabs and they are not really an alternate way of doing the same thing. It's like saying _You have a Honda Civic, why do you want a pickup truck?_ Well try loading 1200lbs of bamboo tongue and groove flooring into the back of your Civic and you'll see why. Both are vehicles but serve different purposes.

Like I said before, take tabs out of Visual Studio, Edge or any other Microsoft product for one release and see the reaction. It won't be pretty. We _can_ all have it both ways. We are asking for tabs to be an _optional_ not a required editor component. Can time be better spent on other editor development? Sure. Critical bug fixes and improvements that block use of the editor should always come first. However, I'm sure there have been a bunch of features added that do not rise to the level of being a critical improvement or fix. So if time is spent on those then there should be time set aside for a feature that the vast majority on this thread are asking for.

We love what VSCode has become in recent months and we are this engaged in this topic because we want it to be the best editor available. There is no room for negativity here. We are all passionate about what we want/don't want as developers. Nobody has a wrong opinion but opposing opinions must be honored as such and not simply discounted because you feel they are invalid.

I don't think there is a lot of "passion for tabs". What happens is that after @bpasero stated "I do not think tabs are a good way to show the list of open files" and "So far I have not yet heard a good reason for tabs", people will get more vocal trying to justify the request to the main project committer.

I'm amusingly frustrated to see all this discussion, and I'm a little bit offended because I use VS Code daily in my work and I want to have a good .NET editor on mac and linux, and I miss tabs a lot, and I didn't get that "_wow! this is actually more useful_" moment, but the response here seems to be "_you just didn't realize we created something amazing! give it time and get used to it!_".

Here are some actual issues I see by using VS Code daily for a couple months:

• it makes no sense to me click the close icon in the window but keep the file in that list - I have to constantly keep cleaning that list manually to have a list where I see only the files I'm actually woking with - and the files I work with are not last ones I open or the ones I'm changing, it's the ones I want to keep open at the same time
• it makes no sense to me to close an unsaved file and have it on that list with a marker - many times a day I do something, and the change is not reflected in the app because I closed the file and VS code didn't ask me to save it, which makes me waste time
• one click opens the file, but only double click to put the file in the recently used section - so, I constantly open files that don't appear there - and then my muscle memory finds it easier to add or remove a space in the file then scroll to the file I'm looking at again and double click it
• I find it annoying that you can't see the scrollbar once the list fills up unless you hover over it. Now, this is complicated because that's how the UI works in the editor. But see, I know the project and I know there must be more files in the folder view. I also know the structure of code, so I know there must be something more in the editor pane. But with the recents list, I have no idea. "Is it full or did I forget to open that file? Didn't I open that file 1 minute ago? Let me open that file again..."

Now, I see that most of this would be resolved with an argument like "_oh, but you're missing the point, it's a recently used files list, not an open files list. You are comparing it to tabs, and there are better ways to deal with open files. After some time you start to..._"

To which I'd gladly respond: "_This whole thing doesn't make any sense to me and is actually making me unproductive. There is already a solution that works everywhere for decades. I don't want to fix something that was never a problem, and I honestly don't see this new solution as a better alternative. Can we just have something familiar that works and we're all used to? Thank you_"

I know all of this sounds arrogant. But I bet this is what most people are thinking but are either too shy or too polite to say.

Experimental UIs are great as alternatives and I'm all for having an option to switch between the two. But this is currently a forced experiment that prevents the other option, which is the most common and expected. And just like the Windows 8 Start Menu there is no way this ends well.

To which I'd gladly respond: "This whole thing doesn't make any sense to me and is actually making me unproductive. There is already a solution that works everywhere for decades. I don't want to fix something that was never a problem, and I honestly don't see this new solution as a better alternative. Can we just have something familiar that works and we're all used to? Thank you"
...
And just like the Windows 8 Start Menu there is no way this ends well.

I couldn't agree more.

As code folding was once the most voted for feature, so now is tabs. The vscode team gave us folding.

I'll be surprised and dissapointed if tabs never come to fruition given the great track record of the vscode team's inclusion of top user requests in light of Microsoft's refreshing participation in the open source community.

@ianwesterfield Exactly, it's the top requested feature with thousands of votes. It's going to happen. This conversation is pointless and needs to move on to "How exactly should tabs work?"

I commented before on the existence of a near-perfect implementation of tabs: Atom. They are easy to organize, have proper display of partial file paths if two tabs have the same file name and work extremely well in a window with multiple horizontal and/or vertical panes (which I think is another needed feature of VSCode). If VSCode had the same tab features as Atom, I think that would cover 99% of what everyone is asking for. And since Atom is also electron-based, implementation can function equally as well in VSCode. I'm not for a copy-cat solution of anything, however they (Atom) have done a great job implementing tabs and what they have is an excellent solution in that respect.

@jon64digital Maybe it's just me, but I think what prevents this conversation from evolving is a sense of frustration. This request is still unassigned in backlog, even with 6k+ votes and a vaguely worded reference in the March 31 iteration:

Improve the document management, stacking behaviour of editors

That feels like we still have to repeatedly justify the existence of tabs, let alone their behavior. At the very least, I suppose, that reference is one of three to Eliminate Adoption Roadblockers, but it's now March 12...

With that in mind, I think if they were to at least assign it to someone we could rest easy in what @waderyan said earlier and perhaps then the conversation can begin to evolve.

EDIT Maybe this lack of commitment from the VS Code team is a misunderstanding - after all the March iteration plan hasn't been updated since January 7.

@jayrosen1576 I agree - and I think the 1% of user requests that wouldn't be covered could then be addressed through extensions (e.g. opening files with relations in tabs groups, etc.).

@jayrosen1576 Does atom allow you to link files so that you can have a split view which (for example) opens toolbar.html in the first frame, toolbar.js in the second and toolbar.css in the third?

This is just an example but it would be absolutely ideal. Somebody above said that Vim can do this but I checked out vim and wasn't keen on it for a number of reasons, but the tab thing sounds superb.

@jon64digital Atom doesn't do this by default, and I'm not aware of any extensions to date that do (even vim-inspired extensions), but this is the extension use-case I was referring to in my last post.

EDIT refer to the comment by @jtosey above (about 9 days prior to this post).

Personally I could see this being an annoyance. Half the time I don't care about the view - just the controller, model and client-side JS. I would probably end up going insane if the view opened every time I opened the JS.

But then again, that's the beauty of an extension - if I don't like it I can turn it off.

When working on feature requests like this one that have a very strong impact on UX, we typically first spend quite some time in UX meetings to discuss how the actual implementation should look like. We had Improved document management on our agenda for quite some time but other things on our GA list simply had higher priority (Accessibility for example).

We will pick this item up after our GA release end of month and start the discussion around how document management should work in the future. We do see some flaws with the current way how things work and know that we need to improve it. We think that even without tabs, there is some things that are simply not very intuitive in the way how the UX behaves today (Close Editor vs. Close File, the fact that side editors are behaving different compared to other editors, working files and quick open, etc.).

While the concept of tabs is well understood, we do not think that we could simply add tabs on top of our existing document management without revisiting our concepts there.

I do think we will have quite some discussions about how document management should work in the future and I think we are up for overhauling the concepts as we see it necessary.

@bpasero after reviewing the code for another issue, I don't understand why it isn't possible to just add tabs or what concepts you would have to change by doing so. It might go a long way if you could enlighten us, or is this a reference to the line of thinking in your original posts?

@bpasero It was nice if you elaborated more on what is discussed and what are some of the approaches you see as possible solutions to the problems we posted.

P.S. I'm not sure whether it's possible with VSCode but some teams like Roslyn, TypeScript and few more share their design notes, it gives a lot of context to how they work and what's coming next, it also opens the community to new discussions, is something like this possible?

@bpasero would the team seriously consider community attempts to add tabs. I don't mind trying, but I don't think anyone wants to waste their time if any effort would be blocked

I think your team is in vapor lock having made this molehill into the mountain.

Meaning: Tabs are constituent to, not synonymous with, the broader concept of document management. There are other issues already filed dealing with other areas of vscode's document management.

We already discuss our UX ideas via issues in the open (see https://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Aux), I would assume we would do the same for document management and tabs.

I also think we would not want these improvements to be done via extensions but rather have them as a core concept in the VS Code workbench.

Once we start the UX discussion in the team we would like to involve the community too and we would then also discuss flaws we see in our current design and what we plan to improve.

@bpasero thank you so much, that's all I wanted to know. :)

@bpasero Awesome. I know you guys are putting a huge effort into the product and we all really do appreciate it. I think many of us just feel some frustration with the lack of tabs in the UI since we rely on them heavily and completely changing the way we work is not really an option. We want this to be the best editor out there and it's really close to accomplishing that.

Without reading this entire thread I give a big :+1: on this.

I have been using for Sublime for years and love the tabs. I see that working files fills some of the gap, but not completely. I can't explain fully why, but please give me my tabs!

+1

Extremely necessary.

+1

I work on many different file types during development so I often like to create a tab group on the right-hand side for one type of file and another tab group on the left for other types of files. For instance, when working on protractor/webdriverjs code, I like to keep all of the "Page Objects" on the right and all of the "specs" on the left, grouped separately and logically. Similarly when working on front-end stuff, I'll keep a tab group on the right for all of the js/ts files and another on the left for html and css.

These are just two examples, but I do this ALL the time on almost every project to some extent and this strategy has served me well for many years of development and I find it extremely helpful.

While Code certainly allows me to have multiple panes, the global file list approach makes it more difficult to differentiate between the file types and thus I find myself wasting a lot of time scrolling thru the list for the file I wanted to view. Additionally, when I (instinctively) try to close just one file on the right pane the entire pane disappears which is extremely frustrating, especially after using regular VS for over 16 years which has trained me to expect the pane to remain open with the rest of the files visible.

The lack of tab groups in Code is extremely disappointing and I don't think people should be forced or convinced to work in a certain way because "it's better" or "there is no good reason for tabs" in your opinion. Yes there is. Maybe you just don't use them in the best way or don't feel they are useful, but there are tons of us who do and would really appreciate something as basic as tab groups.

My understanding is that Code is based on Atom which already has tab group support. It would seem that it would of taken a lot of extra work to remove this functionality, which just doesn't make a whole lot of sense to me. At the very least allow the user to pick which experience they want so they can use Code in the way works best for them.

Please bring tab groups back to VS Code.

Maybe if you draw boxes around the filenames in the Working Files list, people will see that it's functionally equivalent to left-sided tabs... :-)

@ChrisMiami: except it's not. (I'd potentially be wiling to live with it if it were.)

LOL

On Thu, Mar 17, 2016 at 4:59 AM Kenneth G. Franqueiro <
[email protected]> wrote:

@ChrisMiami https://github.com/ChrisMiami: except it's not
https://github.com/Microsoft/vscode/issues/224#issuecomment-166931316.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-197603728

@kfranqueiro while waiting for a proper tab solution you might be interested in adopting the keybindings I use which bring ctrl+w and ctrl+shift+w closer to a regular tabs implementation.

@nub340 VSCode isn't based on Atom but Electron which was made by the same group that is working on Atom.

+1 Please add!!!

I also think this is a feature sorely missing in an otherwise great editor.

Please add tabs as an option, or allow third party plugin for tab functionality.

The first thing that struck me about VSC (after the silly name) was how _great_ it was to _not_ have tabs.

I currently have 8 files open -- tabs are pointless for me, because the file names will not show on the tabs.

I _adore_ CTRL+TAB, and the 'working files' list.

If you must add tabs, please make them optional.

@leegee They are not "pointless", you just don't have a need for them. Did you consider that people who are working on different kinds of projects might have a different use case to you?

Give the thousands of people who have voted for tabs, I think the only "pointless" thing around here is your comment :)

@jon64digital : I saw that the project had asked for general comments from users on the prospect of tabs -- I took that to mean we should express our own opinions. I now realise I should have e-mailed you first, so that I could express your opinion, and avoid your rude ad-hominem invective. My apologies.

@jon64digital @leegee said they were pointless _for him_, not in general. I wholly support tabs but I do agree that they should be an option that can be turned off for those that do not use them. Let's keep the discussion civil and not resort to personal attacks. Nobody has an incorrect opinion. They are just that...opinions.

@jayrosen1576 He has edited his comment. If it had originally said "pointless for me" then of course I wouldn't have said what I did. I also presume that the two other people who downvoted his comment did so before he edited it.

I totally agree that everybody is entitled to an opinion, but there seem to be several people on here that don't require tabs in their workflow who are seeking to deny those who do want them by putting -1 or telling MS that the feature is not required or would in some way divert resources from more important features. Given that they can see how many people want tabs, I find this selfish and a little immature.

Anyway, I apologise if anybody saw this as a personal attack. I did put a smiley after it.

If anything I think this discussion just illustrates that there are many ways a developer can use an IDE and all of them are perfectly valid for their use case. There is no one "right" way and at the end of the day it's just a tool to get the job done. Some devs like tabs so they can arbitrarily group like files and others find a single MRU list perfectly adequate. Then you have those who just use notepad for everything and we're all a bunch of pansies ha-ha.

Seriously tho I just feel that since tabs have been an essential part of Visual Studio for pretty much ever, there are a lot of developers who have grown accustomed to their utility and therefore making the single MRU list optional (either opt-in or out) would make the already awesome tool that VS Code is even more versatile, for all.

@nub340 exactly! some of us like tabs because they were always part of our experience as developers/users, personally I like to see the files that I'm working on at the top, there's no inherent advantage to tabs over working files but that's just how some of us like it.

Agreed, I would like it as an option, not force it.
On Tue, Mar 22, 2016 at 6:22 AM Eyal Solnik [email protected]
wrote:

@nub340 https://github.com/nub340 exactly! some of us like tabs because
they were always part our experience as developers/users, personally I like
to see the files that I'm working on at the top, there's no inherent
advantage to tabs over working files but that's just how some of us like it.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-199565160

We didn't have tabs on the Vic-20....

One thing that comes out of this discussion is that whatever is (made)
available, it should be customisable.

@glennblock, @leegee yeah it should definitely be an option but shouldn't the working file get the same treatment for these who don't want it? however, it's probably best to discuss it in another feature request. :)

I have posted this text here: https://github.com/Microsoft/vscode/issues/101

It is also valid for this discussion. I would be glad to see @bpasero response.

I want this feature. End of discussion. Fuck your opinions @bpasero I don't care what you think is right and what not. The same is about tabs #224. You are trying to convince us that your solution is better. Once again fuck your solution. We all do stuff differently and nobody cares what you think. I'm using vscode just becasue of great support of typescript and angular2. Otherwise I hate it because it lacks features that normal editors have e.g SublimeText, Atom, Brackets

Haha @PeterMtj , thanks for saying what we're all thinking :)

@bpasero seems to have a habit of voting down and discrediting any feature that he would not personally use himself and doesn't fit his personal workflow.

People use Microsoft software mostly because they have to , rarely because they like it, and when you see that Microsoft staff have attitudes like his it just goes to show why they can't design a decent piece of software like Sublime Text. I have tried my hardest with VS Code but I am very close to uninstalling it.

@PeterMtj Seriously? that's how you approach things? curse people? if you don't have respect for him then have some respect for yourself!

@jon64digital He can vote down or say his personal opinion and that's fine! we don't need to get personal and certainly not curse people for their opinions!

I disagree with his initial response too, saying "No" is not professional and quite rude in my opinion but I think that the community can do better and stay civilized regardless to people's opinion.

People use Microsoft software mostly because they have to , rarely because they like it, and when you see that Microsoft staff have attitudes like his it just goes to show why they can't design a decent piece of software like Sublime Text. I have tried my hardest with VS Code but I am very close to uninstalling it.

Edit: People don't have to use Microsoft products! I certainly do not have to do that and saying that people do that rarely because they like it, it's just trash talking! Microsoft make some great products and great technologies and I'm far from being a fan of everything they do but they certainly do some things right! no one forces anyone to use VSCode and if someone forces you to use VSCode then he/she should be fired because you need to choose your own tools! the only thing an employer should care about is your job not how it's done!

Let's not turn this into a flame war and keep it constructive, please!

@eyalsk

I wasn't trying to start a flame war, or talking trash, but I 100% stand by what I said. MS have historically tied their own products to their OS and to each other to force people to use their software because they know it's not good enough to stand on it's own. I know plenty of people who have to use MS Office at work, I've had to use Visual Studio before because I had no other choice and I could count the number of people who would voluntarily use Internet Explorer on the fingers of one hand. They've even been the subject of anti-trust suits because of these practices, so to say that nobody is making anybody use MS software is naive.

Things have moved in the right direction recently and they're becoming more platform agnostic and trying to make their software interop better with others. I'm sure there are good people at MS trying to make great software and giving people what they want, but bpasero clearly isn't one of them. His closed minded attitude is not a credit to them and I thought it was funny that @PeterMtj called him out in that way. We're all adults here and nobody should be offended by the odd swear word. It's just a word.

You've got a long thread here with hundreds of people telling MS EXACTLY what they want out of a code editor. It's not as if they don't know what we want. Then we have an MS employee on here saying "no, you're basically all wrong". Doesn't that paint a picture of a company not exactly in tune with their audience?

Just my 2c.

@jon64digital

I wasn't trying to start a flame war, or talking trash, but I 100% stand by what I said. MS have historically tied their own products to their OS and to each other to force people to use their software because they know it's not good enough to stand on it's own.

That's just your bias assumption and I respect that but we can say the exact same thing about any other corporation in the world to name a few Apple, Oracle and Google...

I know plenty of people who have to use MS Office at work,

People aren't forced to use MS Office, that's the decision of the employer, Libre office is a great product and it's quite good alternative.

I've had to use Visual Studio before because I had no other choice

I don't know _why_ you had no choice but you definitely have choices today! I always had a choice even when people used Visual Studio heavily for .NET development I used SharpDevelop, Vim and Notepad++, I never had problems using multiple editors, I'm not a fan of designers anyway...

For C/++ you have even more support from editors and IDEs unless you use VC++ :)

Besides, I never understood why some people are locking themselves to a specific stack of technologies made by X, there are many technologies out there beyond say Microsoft.

I could count the number of people who would voluntarily use Internet Explorer on the fingers of one hand.

You're right Internet Explorer was very bad up to version 9 but they have improved quite a lot since then and even though I'm a FireFox user, I don't judge Microsoft for their past, I judge them for who they are at the present and it looks good!

They've even been the subject of anti-trust suits because of these practices, so to say that nobody is making anybody use MS software is naive.

No one is making anybody use anything and I don't know about most people but I'm far from naive, I'm just reasonable.

If your employer makes the choice to use MS technologies, then you are certainly _forced_ but again it's not Microsoft's fault, if you made the choice to use MS technologies then you chose it and complaining about it is a bit silly, there are equivalent technologies that are as good as Microsoft ones so people certainly have choices.

Things have moved in the right direction recently and they're becoming more platform agnostic and trying to make their software interop better with others. I'm sure there are good people at MS trying to make great software and giving people what they want,

Exactly! even though I don't think that giving people what they want is good from a design standpoint. :)

but bpasero clearly isn't one of them. His closed minded attitude is not a credit to them and I thought it was funny that @PeterMtj called him out in that way. We're all adults here and nobody should be offended by the odd swear word. It's just a word.

I don't think we need to define people based on their opinions, certainly not these kind of opinions and being an adult doesn't make people vulnerable to personal attacks of any kind, swearing a person isn't pleasant and should be discouraged, acting as an adult means you can control your rage and write your opinion about someone or something without being offensive.

You've got a long thread here with hundreds of people telling MS EXACTLY what they want out of a code editor. It's not as if they don't know what we want. Then we have an MS employee on here saying "no, you're basically all wrong". Doesn't that paint a picture of a company not exactly in tune with their audience?

That's a fair point and complaint, I'm not saying otherwise! but @bpasero already stated that once they will work on the UX they will tackle this problem too "_Once we start the UX discussion in the team we would like to involve the community too and we would then also discuss flaws we see in our current design and what we plan to improve._"

@eyalsk Yes, that's exactly how I approach this and I won't take it back. I did not offend him as a person. I offended his opinion on this and his crappy alternative to tabs. That's a big difference. If you don't see it, think again.

@jon64digital is right about @bpasero attitude. I don't know what to think about him. Maybe he just want to get rid of work by saying you are wrong and it is not needed. In either way @bpasero probably should not be communicating with community with his attitude. That's my opinion.

Try to realize that Microsoft is not helping us. We are helping Microsoft by using his products and by giving feedback so they can make decent product. This should not be a discussion about defending tabs, but about how tabs should work so it is in nature with vscode. Vscode is for community, that's us and in extreme case if we all would want red dinosaur in the middle of screen they should do it without questioning reasons. We all have our own reasons. Otherwise vscode is useless for community. That's how I see it.

@PeterMtj I guess we'll have to agree to disagree. :)

I wanted to jump in and provide some additional background for this issue. We are just about the wrap-up a major milestone of Code. A key focus for us in the last 6 months was support for accessibility and localization. This has left us no cycles in the UI area to actively work on the Tabs feedback. Now that most of the check boxes on the March plan (#3555) are checked, we are slowly starting to look up again. In April we will ramp up on this topic. @bpasero played a key role in the development of our UX and this will be the next major evolution.

Thanks everyone for your passion and feedback, helping us make VS Code the best product it can be.

TIA for the accessibility additions - will make a big difference for us
half-blind

On Sat, 26 Mar 2016, 01:38 Erich Gamma, [email protected] wrote:

I wanted to jump in and provide some additional background for this issue.
We are just about the wrap-up a major milestone of Code. A key focus for us
in the last 6 months was support for accessibility and localization. This
has left us no cycles in the UI area to actively work on the Tabs feedback.
Now that most of the check boxes on the March plan (#3555
https://github.com/Microsoft/vscode/issues/3555) are checked, we are
slowly starting to look up again. In April we will ramp up on this topic.
@bpasero https://github.com/bpasero played a key role in the
development of our UX and this will be the next major evolution.

Thanks everyone for your passion and feedback, helping us make VS Code the
best product it can be.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-201618115

@egamma I really thank you and your team for everything, i think you're doing a great job! but I feel like the first response made by @bpasero got people irritated and this could have been avoided if he gave insights to why he thinks tabs shouldn't be an option instead of just saying "No".

Anyway, let's focus on the present, is there any new build before the //build/ event? :D

@eyalsk I believe the "No" comment was actually referring to the first reply from @inakianduaga, in that it's not possible to implement tabs using the current extension API. I think this was misunderstood as saying that tabs will never happen, however the issue probably would have been closed if that was the case.

@Tyriar, gotcha thanks! :)

Anyway, let's focus on the present, is there any new build before the //build/ event? :D

The bits for the new build are already waiting for you on the insider channel (release notes) please use it and give us feedback.

@egamma thanks! ;)

We're starting the design work on this experience and would like to involve the community as much as we can. I will be running regular design discussions as we make progress to get your feedback. Most often these will be one on one sessions where we share what we are working on and discuss them with you.

The first sessions will take place this Wednesday. Please sign up here if you are interested: https://calendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016

Awesome!
On Mon, Apr 4, 2016 at 3:54 AM Steven Clarke [email protected]
wrote:

We're starting the design work on this experience and would like to
involve the community as much as we can. I will be running regular design
discussions as we make progress to get your feedback. Most often these will
be one on one sessions where we share what we are working on and discuss
them with you.

The first sessions will take place this Wednesday. Please sign up here if
you are interested:
https://calendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-205239769

Looking forward to hearing your feedback on new designs we're exploring related to this issue. If you're interested, please sign up via the link on @stevencl's comment above!

3 and 4am only? No other times? I can't make 3/4 am PST on a Wed.

On Mon, Apr 4, 2016 at 8:14 AM Brad Gashler [email protected]
wrote:

Looking forward to hearing your feedback to new designs we're exploring
related to this issue. If you're interested, please sign up via the link on
Steven's comment above!

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-205342923

It would be good if you have timing according to PST, many (including me) can participate 

{Mobile}

On Mon, Apr 4, 2016 at 8:50 AM -0700, "Glenn Block" [email protected] wrote:

3 and 4am only? No other times? I can't make 3/4 am PST on a Wed.

On Mon, Apr 4, 2016 at 8:14 AM Brad Gashler [email protected]

wrote:

Looking forward to hearing your feedback to new designs we're exploring

related to this issue. If you're interested, please sign up via the link on

Steven's comment above!

—

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub

https://github.com/Microsoft/vscode/issues/224#issuecomment-205342923

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

Yes please. I def would like to be part of the conversation.

Sorry, I know these times aren't convenient for everyone. In the future we will look into ways we can schedule sessions in different time zones as we plan to hold them on a regular basis.

Why not just schedule an additional one this week at a diff time? This is a
hot topic with a lot of interest.

On Mon, Apr 4, 2016 at 9:44 AM Steven Clarke [email protected]
wrote:

Sorry, I know these times aren't convenient for everyone. In the future we
will look into ways we can schedule sessions in different time zones as we
plan to hold them on a regular basis.

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-205386984

Just so you know, the time slots that you see are just the ones that are still available. I had slots open later in the day but those were taken quite quickly.

Like I said, we will try to schedule sessions in different time zones in the future.

Thanks for all the interest.

I see, well I guess they filled up instantly (which is good)
On Mon, Apr 4, 2016 at 11:30 AM Steven Clarke [email protected]
wrote:

Just so you know, the time slots that you see are just the ones that are
still available. I had slots open later in the day but those were taken
quite quickly.

Like I said, we will try to schedule sessions in different time zones in
the future.

Thanks for all the interest.

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-205436942

Can you / do you record the sessions?

On Mon, Apr 4, 2016 at 11:32 AM Glenn Block glenn.[email protected] wrote:

I see, well I guess they filled up instantly (which is good)
On Mon, Apr 4, 2016 at 11:30 AM Steven Clarke [email protected]
wrote:

Just so you know, the time slots that you see are just the ones that are
still available. I had slots open later in the day but those were taken
quite quickly.

Like I said, we will try to schedule sessions in different time zones in
the future.

Thanks for all the interest.

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-205436942

Wish I had seen this earlier so I could have signed up. For what it's worth, I hope you never implement tabs. I have progressed from vim to TextMate to Sublime to Atom and now to VS Code (with a lot of IDEs along the way), so I have had a LOT of experience with tabs. To me they are a crutch that people use and never get past. Managing many open tabs on a large project is an exercise in frustration that adds one more chore that I don't need. Forget to close a few and it quickly becomes hopeless. To those few of you who have the discipline to never encounter this, kudos. But why spend the mental energy on an unnecessary task?

More importantly, I think tabs cause people to think in terms of FILES, when (for most code development) they should be focusing on functions, classes, namespaces - symbols. Files are an implementation detail in most cases that should not dominate your navigation. I think VS Code has a real opportunity to provide something new and better.

I realize that this is just MY preference, and I understand why a lot of people are asking for tabs to be optional. This may seem like a reasonable compromise, but it would be difficult to support two different navigation workflows well. Just try turning off the tabs plugin in Atom and see how many things don't work or work poorly because developers expect tabs to be there. So for my own selfish reasons I want the VS Code developers to focus on navigation that isn't tab (or even file) based.

Ditto @indiejames

If you implement tabs, please support multiple rows for many files. I hate having a scrollbar on my tab bar. My favorite tabs implementation is Tabs Studio. See also how files with the same basename can be automatically grouped together.

My workflow I open tabs while I work in Sublime as I need to. I don't leave tons of tabs open and I often use "close all" to bring things back to a clean slate.

I have been developing over 30 years across multiple IDEs and text editors. I don't see tabs as a crutch, the are a useful organizational tool. Yes they can get out of control if you have zillions of tabs, but I don't....

In terms of tabs leaning toward focus on files and such, code lives in files, and files ARE used for organization, and VS code is built around managing folders and files of code.

I totally get some may prefer not having tabs and I am not saying to get rid of what is there but having a supported tab workflow would be nice.
On Tue, Apr 5, 2016 at 7:32 AM error [email protected] wrote:

If you implement tabs, please support multiple rows for many files. I hate
having a scrollbar on my tab bar. My favorite tabs implementation is Tabs
Studio https://tabsstudio.com/.

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-205834354

"It makes it easier for users to misuse the product" is a terrible reason to not support a feature. The tool is there to _facilitate_ workflows, not to _dictate_ them. If a user can't find a comfortable workflow, that user is more likely to choose another tool where they can, rather than adapt to an unfamiliar paradigm.

I'm currently working on a few closely related files, jumping back and forth between them. Every time I need to switch, I need to choose from the sidebar or a drop down, which takes 3-4 times as long as a tab.

@indiejames

but it would be difficult to support two different navigation workflows well. Just try turning of the tabs plugin in Atom and see how may things don't work or work poorly because developers expect tabs to be there. So for my own selfish reasons I want the VS Code developers to focus on navigation that isn't tab (or even file) based.

It's not too difficult to support two different navigation workflows or even more than two, what's really difficult is getting the design right!

If you really want to support tabs and working files or another workflow you need to go few steps backwards, do a zoom out and redesign navigation from the ground up, making workflows a strategy that people can choose from.

Creating an extension just to have tabs in the editor without considering use cases and how people are working with tabs or another workflow is just missing the cause which adds no real benefit and thus most likely be a failure.

There's a difference between code navigation and file navigation, when you code you surely need to
think about symbols rather than files but code lives in files and sometimes you need to deal with it too e.g. I don't open many tabs but when I'm working on multiple projects I usually have one file per project open that are related, I use hotkeys heavily but because tabs are always at the top, and when I look at the editor they are always there, it's probably psychological but it just helps me focus.

Your experience with tabs is unfortunate and I don't underestimate your experience at all, I don't know how you work but many of us like it and use it with great success.

I don't think that one experience is better than the other but having different experiences or even hybrid can be helpful and editors should honour my experience not go against it.

It would be quite helpful for us who can't make the meetings due to other commitments to be able to give feedback.
Maybe, once the meetings are over on the 1st day, post a video of a meeting(with all involved's permission) which others can view and comment on within the remaining time for meetings?

Obviously it can't be a long period but more feedback can't hurt with hopefully some different view points added.

I really hope some Python devs and c/c++ devs will be in the meeting as their workflow is different to a JavaScript dev's workflow

Thanks Steven for taking the time to talk with me!
This engagement with the community is really encouraging, and I'm enjoying
following the vscode development!

On 6 April 2016 at 19:41, Michael Wallace Louwrens <[email protected]

wrote:

It would be quite helpful for us who can't make the meetings due to other
commitments to be able to give feedback.
Maybe, once the meetings are over on the 1st day, post a video of a
meeting(with all involved's permission) which others can view and comment
on within the remaining time for meetings?

Obviously it can't be a long period but more feedback can't hurt with
hopefully some different view points added.

I really hope some Python devs and c/c++ devs will be in the meeting as
their workflow is different to a JavaScript dev's workflow

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-206261939

Thanks @TurkeyMan, great chatting with you earlier today.

For everyone else who hasn't been able to participate we will be running these on a regular basis so there will be opportunities to participate at a later date.

The conversations we are having this week are all 1:1 conversations during which we discuss the details of the problems that each individual has experienced. This allows us to get a deeper understanding of the problems that we need to solve.

In subsequent weeks when we will be reviewing design mockups we will look for ways to have group discussions as well as 1:1 discussions. We will also look into how we can record and post videos of meetings afterwards.

@stevencl is it possible to post a summary of the sessions (or even better, recordings) for those of us who are unable to participate, but are still interested in providing feedback.

+1
On Wed, Apr 6, 2016 at 7:36 AM Peter Petrov [email protected]
wrote:

@stevencl https://github.com/stevencl is it possible to post a summary
of the sessions (or even better, recordings) for those of us who are unable
to participate, but are still interested in providing feedback.

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-206405009

I would like to chip in on my expectations of file navigation within a code editor. I've been trying to get used to VScode for weeks now and keep going back to Sublime. Here is what I expect:

1. mouse-less navigation
2. ability to navigate forward and back within the set of open files
3. easily close files

So far I found VScode to unfortunately fail for me on all three. The workspace is unintuitive because when I close a file, it's doesn't really close, it's simply no longer editable. Closing the file is a mental activity of removing it from the set of files I'm working with.

In VScode, when I navigate within the files that are opened _in my head_ I keep encountering "garbage" that I thought was previously thrown away. This is exceptionally distracting and I end up having 20-ish files opened in workspace and eventually can no longer keep track of it and just close them all.

I'm unable to use the keyboard to quickly switch between opened files, that _in my head_ form a linked list. The order that I open them in is just as significant as the order that I close them in. I find Ctrl+Tab useless because I have to read file names one by one in that list and then figure out which one to tab to. I can much faster to flip through 5-8 opened files to the right one by simply recognizing content while it's flashing by or by just knowing where in "the list" my desired file is in.

I hope that makes some sense. I try to optimize my workflow as much as possible, use keyboard and avoid the mouse because it slows everything down tremendously. I struggle with this in VScode more than I have previously in any other editor (textmate, vim, sublime, flash, eclipse, etc...)

Just to reiterate, any recordings of meetings that happen this week won't be made available as each meeting is a 1:1 conversation where each person discusses the details of how they work and the specific problems that they have with VS Code. During these conversations we won't be going into great detail on any designs.

In subsequent weeks though we will look for opportunities to record and make available meetings where we discuss designs for improving document management in VS Code. Look for another invite from me some time next week to participate in the next round of design discussions.

Thanks for all the feedback and the details of how VS Code does or does not work for you.

Just because no one seems to have mentioned it and I suspect that I am not alone on this: for me tabs in an editor is all about spatial memory - i.e. where am I, and where is the stuff around me?

We live in a physical world. We've evolved to understand and make intuitions about the space around us and we do it without thinking. This is why we can type without looking at the keyboard - we "just know" where the keys are and can type away at speed. With tabs, our default-issue wetware we were born with can kick-in and we know "where" a file is in on the screen and we can hone in on it without thinking because its instinct that we use everyday. I "put a file down" as it were via a tab in the editor, and can remember "where I left it" in exactly the same way that I can remember where I put my TV remote down next time I need to change channel (assuming I had a TV any more)

For me, a time-ordered file history flies goes totally against this intuitive understanding of space. If I know that "main.java" or the T key on my keyboard is in a certain position, I do not want it to move unless I physically & deliberately move it. If it moves on its own, I need to stop and think and find it. Imagine a TV remote with wheels that moved itself around your house on its own, or a keyboard that re-arranged the keys based on how recently you used each letter! It would be chaos! :-)

I really like VSCode, but I am personally frustrated & slowed by the lack of tabs. Keep up the good work - I look forward to seeing what you come up with!

@matt1
What you are describing is exactly what makes tabs so limiting (for me). Tabs are a metaphor for the physical tabs placed on files in a physical file cabinet, and have all the same limitations. I would rather have an automated file cabinet in which I can type a few keys and jump to my information than a physical one where I have to sort things myself and manage the limited space for visible tabs.

I'm curious - do you navigate tabs using the mouse/trackpad or using key combinations on other editors?
If you use keyboard shortcuts exclusively then perhaps you have some tabs workflow that I'm not aware
of and I would love to see it. I suspect, however, that a lot of people use the mouse/trackpad - not realizing how unproductive that context switch is and how much it is slowing them down to take their hands off the keys. It's easy to learn and easy to understand, but less powerful/productive than using key combinations. If you find yourself "reaching for a tab" with the mouse it may be intuitive and it may take advantage of your spatial sense, but it is slowing you down. Not so much in the time lost to the physical motion, but in the context switch itself.

I realize these are just my opinions and most people disagree with them, but it's Visual Studio _Code_ . For coders/developers. And developers realized a long time ago that shell > gui for most (not all) things, and that desktop metaphors, while easy to learn, are quite limiting.

So is it _just possible_ that some of you saying "I can't live without tabs" have not explored other workflows? If so, isn't it worth trying it if the payoff would be increasing your productivity?

To those of you who have tried to work without tabs and cannot adapt or honestly feel tabs make you more productive, I can accept that this is just an honest disagreement. But to those who argue for physical metaphors because "they've worked for 30 years!" I would ask do we really need _another_ TextMate/Sublime/Atom? Shouldn't we be trying to move the envelope?

I have no doubt that I'm in the minority here (but that doesn't make me wrong), so this is the last comment I'm going to make. Feel free to pile on :)

Decided to check out VS Code to see if it could be a free replacement for Sublime, but without tabbed documents, it's a non-starter. Being able to set VS Code in single-instance, have multiple documents open, and easily switch between them is a basic requirement of any text editor. Keeping Explorer open is a work-around, but it's no unnatural to have left tabs instead of top tabs like in VS, browsers, Sublime, etc. Ctrl-Tab has several issues, one is having to look at the keyboard and move a hand (for something other than the mouse), the other is that it's non-intuitive. Anyone suggesting that an editor without tabs is anything more than BloatedNotepad has clearly never done any serious editing of multiple documents, such as is required when debugger-stepping through something that had more than 1 file as compiler input.

@indiejames
Tabs are not about productivity for me. Its about cognition.

I've personally never found that raw typing speed has ever been the limiting factor in my productivity. Programming requires thought and consideration - a few clicks are not a problem in the grand scheme of things for me considering how much time we spend _thinking_.

@indiejames I use ctrl+(shift+)tab to navigate between tabs plenty, not necessarily mouse. One of my biggest gripes with working files is the same as @matt1's - the fact that ctrl+tab operates in most-recently-used order. I don't necessarily remember what file I looked at last and second-to-last, but it's very easy for me to see/remember what order I opened them / arranged them in. Sublime Text also defaults ctrl+(shift+)tab to MRU order; I always change it, since it has commands for both MRU and visible order.

I remember back in the day some Web browser (was it pre-blink Opera maybe?) used MRU for ctrl+tab by default too, presumably figuring that since OSes do it for apps, a browser might as well do it too; I found it to be dreadfully unintuitive though, and had to pay extra attention to find what I actually wanted to switch back to...which, guess what, makes the process _slower_.

The argument of using quick open exclusively also works just as well in Sublime Text with tabs as it does in VS Code with working files. Tabs do not prohibit that workflow at all.

For those who prefer the current Working Files approach in VS Code, how many of you actually prefer to click on files within the list of Working Files as opposed to the following workflows?

• using Ctrl + E / ⌘ + E to quick open recent files.
• using Ctrl + Tab to switch recent files

By the way, for those who prefer tabs, your feedback has been very helpful as we investigate adding them to the product. Thanks so much for continuing to share!

@bgashler1
I prefer the keyboard shortcuts. Not so I can be the fastest typist, but because I find them less distracting then moving the mouse/trackpad.

I think what many of the "Working Files and No Tabs EVER" crowd are missing is they _way_ in which many of us use tabs. For example, when I work on an MVC application (web, mobile or desktop) I tend to have tabs in one or more vertical panes (which VSCode is also in need of) in a specific order: Model file, View File, Controller file. So a setup I have frequently open looks like this:

Left Pane

Model 1 File (tab) | View 1 File (tab) | Controller 1 File (tab)

Right Pane

Model 2 File (tab) | View 2 File (tab) | Controller 2 File (tab)

This setup allows me to quickly select the Model files for both components I am working on for comparison or View Files when I have my UI/UX hat on. This absolutely CANNOT be accomplished efficiently with working files, especially if you have other files open as well (i.e. CSS, db scripts, etc). I do a ton of UI/UX and this is by far a common practice. Were I strictly a Java backend developer or a DBA, then no, this would not be a requirement. But for the vast majority of us full stack web & mobile developers, not having tabs (and tabbed vertical / horizontal panes) is an extreme hinderance. While I am making due with VSCode in the short term, I am having serious reservations sticking with it because of this missing capability. No one can convince us that tabs are useless and a working files list is not an innovation (Adobe Brackets also has a working files list and it has been around since 2012).

Again, this is not an all or nothing problem. We are simply asking for the same capability that exists in other editors as an option even if that capability is turned off by default. If VSCode were to implement tabs / window panes exactly as Atom does, it would solve 99.99% of our tab-related griping. I know it is not a trivial task to implement, however I think many of us would be satisfied waiting a bit longer (months, not years) for this feature to be done correctly rather than it remaining in the backlog.

Just my 2¢...

While I've communicated most of this to @bgashler1 already, I'll do a little write up here explaining the ideal behavior for me.

1. Keybindings should close working files, removing them from the working files list and the MRU (most recently used) stack. I have the follow keybindings to accomplish this:

json { "key": "ctrl+shift+w", "command": "workbench.files.action.closeAllFiles" }, { "key": "ctrl+w", "command": "workbench.files.action.closeFile" },

1. Files in the editor should be "stacked", so that when you close one file, the last file in the MRU stack is shown.
2. ctrl+shift+t should restore the most recently closed tab. This keybinding conflicts with workbench.action.tasks.test in vscode but it's a very standard hotkey in tabbed environments. I created a feature request for the command here https://github.com/Microsoft/vscode/issues/3989
3. ctrl+tab and ctrl+shift+tab should only rotate through files in the "working files" list, not files that were "previewed" (single click in explorer and then navigate away).
4. I want my working files laid out along the top of the editor. The reasons for this are:
   
   
   
   • I want to be able to see my working files visually, regardless of which sidebar I have opened. Related: https://github.com/Microsoft/vscode/issues/3360
   
   
   • Over the nearly 2 decades I've been programming I've been looking above the editor for my working files. It's a hard habit to break.
   
   

@bpasero

By the way, for those who prefer tabs, your feedback has been very helpful as we investigate adding them to the product. Thanks so much for continuing to share!

I use Ctrl + Tab quite a lot in VSCode but I think that the experience in Visual Studio is so much better because besides files I can also I can navigate to other parts of the UI, I use it to navigate to the Package Console Manager, Solution Explorer etc...

@Tyriar Great points!

[Philosophy Warning!]

Why is ctrl+tab so much more useful than the 'working files' concept, as it stands? This is the crux question. Personally, I think there are two issues at play.

Firstly, ctrl+tab is a keyboard shortcut and keyboard shortcuts are subconsciously associated with the caret - the user expects that ctrl+tab will change the file in the current editor, where the caret currently is placed, and that's precisely what it does. This is unlike 'working files' or the navigator which aren't associated with a particular editor - they're horizontally distanced from all but one editor and associated with the _most recent_ editor - and are typically used with the mouse. Even if you use them with the keyboard, you've departed from your caret by the time you select a file.

Secondly, ctrl+tab shows you _all_ the files you've seen, recently, in reverse chronological order. 'Working files' shows you only the ones you either double-clicked or made changes to and in the order that you bothered to open them. The criteria and ordering are arbitrary and have nothing to do with the way programmers think - jumping back and forth between caller and function, class and consumer.

(Opinions. Mileage may vary.)

EDIT: My point is this: understanding why one feature works and one doesn't will help to either fix the feature or design a better one. As it stands, working files don't.

@Tyriar: Personally, I really hate the fact that single-clicked files don't show in Working Files. I want ALL the files I've seen in my recently-used stack - even read only, external ones. I opened them for a reason. If I'm done with them, they'll sink out of the list soon enough. At best, there should be an option to make single-click and double-click behave the same.

I figured out how to get most of what I was missing from sublime in the context of this issue:

[
  { "key": "cmd+w", "command": "workbench.files.action.closeFile" },
  { "key": "cmd+shift+]", "command": "workbench.files.action.openNextWorkingFile" },
  { "key": "cmd+shift+[", "command": "workbench.files.action.openPreviousWorkingFile" }
]

@stephenmartindale I'm not sure if anyone has done a feature request to disable 'preview files' yet.

@stephenmartindale we are looking into a way to pin "preview files" to remain open—including read-only files.

We'd like to keep "preview files," because many times people don't know what file they're looking for until they've opened several (which can result in an undesirable number of open files that are irrelevant).

I really love Sublime's flow here. Single click you jump to the file,
double click it stays open.
On Sat, Apr 9, 2016 at 11:49 AM Brad Gashler [email protected]
wrote:

@stephenmartindale https://github.com/stephenmartindale we are looking
into a way to pin "preview files" to remain open.

We'd like to keep "preview files," because many times people don't know
what file they're looking for until they've opened several (which can
result in an undesirable amount of open file clutter).

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-207830702

@Tyriar, @bgashler1, @stevencl I think that it's better to have two new posts for tabs and working files to gather feedback.

Just my opinion but I feel like it would be much better than discussing both features here, this one is long enough. :)

👎 Please don't do this, or at least make it optional. The clean tab-free UI is one of my most loved things about VS code.

@tobico It doesn't have to be all or nothing... you know, as far as I concerned I want both the working files and tabs to be optional and yet integral to people that want to have that experience.

I would like to second that Ctrl+W should close not only the current editor, but the corresponding open working file. For me that's the biggest drawback in the current implementation. That and the fact that Ctrl+Tab lists all recently files, not just the ones in working files. On second thought, a third caveat would would be that single click doesn't open a file as a working file, but editing it does.

+1

@csholmq you can do that now, see the custom keybindings in https://github.com/Microsoft/vscode/issues/224#issuecomment-207507479

@Tyriar That addresses almost all of my caveats. Thanks!

Within 3 minutes, I stopped using VS Code and went back to Atom. No tabs, no go. Sorry, my workflow has been drilled into me. I would bet a quick poll 4 years ago would have gotten your UI answer much faster. But leave it too Microsoft arrogance to fix something that's not broken.

@zunama we haven't forgotten about users who want tabs and improved document management. Now that we're 1.0, it's one of our highest priorities to address these concerns. Awesome things are coming to VS Code soon.

As a web developer, Tabs are important to me. Unlike desktop programmers (who mainly focus on single file at the time), we always switch between windows & using Mouse at the same time (e.g., Slicing an image from Photoshop, and then back to editor immediately. Or debugging in browsers, and go back to another file to do fixing). With tabs, we can navigate to target file quickly. With shortcuts, it's 2 more steps. With sidebar "working files", it's less space in the main code area (as we put Photoshop & Editor or browsers side by side). Height in editor are less necessary. You are always able to memorize few more lines, don't you?

Also, Top Tabs are better for human eyes. You can scan the top tab title and main area code at same time. But you can't read left working files with the main code together. Try it yourself. Furthermore, Tabs are wider, better for mouse movement. (Even you won't focus on it, it's more predictable)

+1/0

+1

Just my personal opinion but please, stop doing -1, +1 posts... I mean besides suggesting that you either like or dislike this feature something that reaction/emoticon can be used for it doesn't say anything about your experience and so if you already writing a post, make sure it's useful! I'm sure you have your own preservative on things and how you would like them to work! otherwise, just use emoticons.

Meta:
@eyalsk In this instance, the discussion is ongoing so that it does indeed seem redundant. But for issues which you wish to gain traction, is really the "Add your reaction" the equivalent? Doesn't that only alert the comment op rather than indicate that the issue is a hot topic? I.e. does it alert devs that are tagged to the issue or set the issue as modified?

@csholmq I don't know if I'm getting you correctly but I wasn't referring to the reaction/emoticons but to posts that contain nothing but +1, -1 in them, it adds no value, a more meaningful input could have been written instead of writing a post with +1, -1... just my opinion, I'll modify and emphasize this in my post.

@zunama It's not arrogance to try look for a better alternative. "Not broken" is no valid argument against looking for new stuff. It's pretty much an argument for it (maybe there's something better?). Though I noticed in this discussion that if VS Code wants to be fully used today it should aim to please the current 'old mindset' user-base and innovate later. Because people aren't very good at waiting and it saves you time trying to argue why this or that is better.

Back to your comment: If you want to do something right, you don't spend 3 minutes and quit. You enumerate your viewpoint on useful critique and look for possible improvements. A viewpoint of 3 minutes is useless - and dangerous - for your design because it's biased.

A poll doesn't work when you want to innovate. Example:

Which of these nagivation styles would be the most productive for you?

• Something. (Try something new that might be better)
• Tabs. (Good old workstyle you learned to love).

Of course tabs would win. But possibly the other idea could pave ways to a new standard navigation UI.

To be honest, one of the defining features of VS Code for me was an absence of tabs. I didn't even realise (at first) that they were missing! It was a very interesting point of view.

Whenever I use tabs, they always get clattered and impossible to find. When I can't see a certain file immediately in the list of tabs, my first reaction is to reopen it. . . and then I would find out that it was already opened. Of course the order of tabs gets seriously messed up in the process. This is what happens to me in Visual Studio 2015.

In the world of everything being the same, it feels refreshing to have an identity.

PS. I am not very impressed with the working files section, however. I mostly use it for quickly viewing which files require saving.

PSS. An idea - if there are tabs in vs code one day, then maybe it will be the best to limit the maximum number of opened tabs, i.e. close oldest tabs automatically when new are opened?

@RussBaz I don't think that limiting the number of tabs is a good idea because that number can change from user to user but maybe this can be an option something like this:

tabs.autoClose = "not-visible", "off", "time", x where x is a number

That's a weird idea. If I like 16 tabs and you like 4, it's simple. YOU use 4 tabs and I'll use 16! Why say your way is better than mine, or vice versa. What is this about anyway? Even the conversation about tabs is kind of pointless as long as tabs are activated/deactivated in Options/Preferences. Those who don't want tabs, GREAT! Those who want them, check the little checkbox! Really, it does not have to be that your way is better than mine, or that I know better than you.
+1
;)

Use case example: I currently switch between 6 tabs constantly in atom.

That grows to around 10 when I need to work on deeper sections. I use them all! So closing and reopening would be a pain. I could have massive files in its place but that would be far far more painful to deal with as then it would balloon to 6k lines in a file if I included every part of a module into a single file.

@Measuring I agree and disagree with you. There are somethings that need innovating but first one has to ask, what about the workflow can we make better by removing tabs. Well for me, every single editor I use for development has a tab interface because it is common for a develops to work between 5-10 files at a time without remembering the exact name of the files nor the order they are opened them in. So I have to ask, how did this new interface make it any better? How is it innovative? First ask, how do they they use it, then ask, how can I make it better.

As for the three minute issue, I am going to assume that Code is not that much different then Sublime (my preferred choice) or Atom (what I am trying out), but if right from the start I struggle to work with it or show someone efficiently what they need to do between files to make something work, then I will use something that works better for my needs now and look into Code a few versions down the road when it is ready. It's not 'old-school' mind set but rather efficiency with my work.

Asking those of us who prefer tabs to switch to no tabs is just as good as
asking those who prefer no tabs to switch to tabs. We both don't want to
switch to the other method.

Can we stop now with the 'Mac vs Windows', 'Android vs IPhone' type of
debates as to which way is better: 'Tabs vs No Tabs'? They are both good
and different people have their own preference.

I think the best solution is to add tabs as a preference that can be
enabled optionally. Then both crowds are pleased.

Is anyone against having both methods as options that you can turn on or
off depending on your preference?

I think it comes down to these two options:

1) Add tabs as a preference. On for those who like it and off for those who
don't.

2) Don't add tabs at all, even if I have the option to turn them off.

Why would you even vote for option 2 when you have the option to turn them
off?
On Apr 15, 2016 7:32 PM, "James McLaughlin" [email protected]
wrote:

@Measuring https://github.com/Measuring I agree and disagree with you.
There are somethings that need innovating but first one has to ask, what
about the workflow can we make better by removing tabs. Well for me, every
single editor I use for development has a tab interface because it is
common for a develops to work between 5-10 files at a time without
remembering the exact name of the files nor the order they are opened them
in. So I have to ask, how did this new interface make it any better? How is
it innovative? First ask, how do they they use it, then ask, how can I make
it better. As for the three minute issue, I am going to assume that Code is
not that much different then Sublime or Atom and if right from the start I
struggle to work with it or show someone efficiently what they need to do
between files to make something work, then I will use something that works
better for my needs now and look into Code a few versions down the road
when it is ready.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-210705545

@tones411 Some people will pick option 2 just because they think that the addition of tabs will somehow ruin their experience with the working files.

_I can't stress it enough_ but in my opinion the discussion shouldn't be about just adding tabs and call it a day but getting the workflow right and I said it many times, meaning, it needs the right options for customization, it needs to feel integrated and not alienated and still optional! same goes for the working files.

Some people may want to have something like Vim buffers and wouldn't want to have neither tabs nor working files at all.

Maybe something like Vim buffers can be used as the surface for VSCode where we can use commands to manage files and then on top of that lay the foundations for each workflow whether it's tabs, working files or another thing tomorrow.

Well said. This has turned into a religious debate. It is obvious from this
long thread that there are many people here that are passionate about having
tabs and believe they are needed / facilitate their workflow. There are
others who do not believe tabs are necessary and that they are an impediment.

Let's just agree to disagree, that's fine. As long as tabs are optional
than those who don't want them don't have to use them.

I personally believe they are useful, but I am not going to stop someone
from using working files if that works for them. It doesn't work for me.
On Fri, Apr 15, 2016 at 10:07 PM tones411 [email protected] wrote:

Asking those of us who prefer tabs to switch to no tabs is just as good as
asking those who prefer no tabs to switch to tabs. We both don't want to
switch to the other method.

Can we stop now with the 'Mac vs Windows', 'Android vs IPhone' type of
debates as to which way is better: 'Tabs vs No Tabs'? They are both good
and different people have their own preference.

I think the best solution is to add tabs as a preference that can be
enabled optionally. Then both crowds are pleased.

Is anyone against having both methods as options that you can turn on or
off depending on your preference?

I think it comes down to these two options:

1) Add tabs as a preference. On for those who like it and off for those who
don't.

2) Don't add tabs at all, even if I have the option to turn them off.

Why would you even vote for option 2 when you have the option to turn them
off?
On Apr 15, 2016 7:32 PM, "James McLaughlin" [email protected]
wrote:

@Measuring https://github.com/Measuring I agree and disagree with you.
There are somethings that need innovating but first one has to ask, what
about the workflow can we make better by removing tabs. Well for me,
every
single editor I use for development has a tab interface because it is
common for a develops to work between 5-10 files at a time without
remembering the exact name of the files nor the order they are opened
them
in. So I have to ask, how did this new interface make it any better? How
is
it innovative? First ask, how do they they use it, then ask, how can I
make
it better. As for the three minute issue, I am going to assume that Code
is
not that much different then Sublime or Atom and if right from the start
I
struggle to work with it or show someone efficiently what they need to do
between files to make something work, then I will use something that
works
better for my needs now and look into Code a few versions down the road
when it is ready.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-210705545

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-210712143

+1

I have been following this thread for the last ~month or so since I switched to Code as my main editor and am continually annoyed by the file navigation behavior. I have spent time _trying_ to get used to the Working Files section, which you admit is more-or-less an afterthought anyway, and Ctrl+Tab, and Ctrl+P. I am super happy with Code and it's easily my favorite editor, but these file navigation options are so poorly conceived it's hard to understand how they were thought up in the first place.

Most of these have been mentioned, but here are my gripes:

The WF list is essentially useless, as closing an editor window does not actually close the file from WF. I need to actually close a file _twice_, and use the mouse to do so (Ctrl+W _and_ close the file from WF panel). If I wanted to leave the file open, I wouldn't have pressed Ctrl+W - how does it make any sense to press Ctrl+W and leave a file "open" (visible in WF). Yes this can be reassigned, but I'm talking about the default behavior of WF).

Clicking a file in WF or tree view opens a file into an undesired editor window at least half of the time. If you have a two-panel editor with active left panel, "open to the side" opens it in the _right_ panel, not a _new_ panel, and with 3 columns it will always open in an existing panel. The problem here is that "things don't stay where I put them." I expect to tell my editor where I want things to be, not for my editor to decide where things should be based on the current UI state and then change them as the UI state changes in other parts of the application. Getting _back_ to a previously opened file is such a PITA.

Single-clicking and double-clicking files has _completely different_ behavior with _exactly the same_ UI. A single click opens the file preview temporarily (for when I dont want to load it into WF because then it will require two closes to get rid of later), but loading a "previewing" editor with another file (unavoidable with current implementation as mentioned above) will jump the folder tree to a new spot, and loading the previous "preview" file means I must again navigate to the folder in the tree view. I don't even want to admit how much time I have spent navigating to the _exact same folder_ 6 times in a row because of this behavior.

In my opinion, single or double clicking a file should give me the _exact same behavior_, but if you really want a single click "preview" that doesn't show up in WF / Ctrl+Tab, there should be an _obvious UI marker_ that the active editor window is a preview and will be gone when you replace it.

The folder tree should _not_ jump to the location of every file I click into, or when I am debugging, jump through every folder in my library folder. If I wanted to navigate to a particular folder, I would navigate to it, and once I've done that I expect it to stay that way. This might seem like its not so relevant in the tabs thread, but indeed it is.,

The only reason these absolutely ridiculous editor panel, WF and folder view behaviors exist is _because there are no tabs_. If you add tabs (docked to a particular panel if the editor panels are split), and default to the normal editor behavior which is to _always open everything in a new tab_, none of that behavior is necessary. Just let me decide how I want to navigate my tree and how I want to stack my tabs, and stop trying to show me a "better way" (unless you actually _have_ a better way - after ~6 months of daily work, I can say with absolute certainty that the current way is _not_ better for me).

And while you're at it, for the love of God PLEASE let me view files from the same directory in more than one window! There is a simple and elegant solution, which every other tab-based software has had for years - drag the tabs off into a new window - seriously folks this is not revolutionary stuff. If you want to maintain the "one folder only gets one instance" behavior, then have the panels float into a new window (that is still controlled by / attached to the main window).

You guys have done an awesome job with this editor and I will continue to use it. If we can see:

1. Tabs
2. Disable WF
3. Stop auto-navigating folder tree
4. Ripoff tabs into floating editor panel (that shares all same behavior as other editor panel in main interface)

Then I think VS Code will go far, far, far. Great editor, and I'm willing to put up with the downsides to take advantage of the rest, but many, many others are just waiting for these few basic features.

I would love to help with UI/UX testing or whatever it is you do for user feedback/input. Let me know if I can be of service.

Thank you!

@anyong thanks for your insights!

For point 3, not sure if you know but you can customize this currently too with:

"explorer.autoReveal": false

I bind workbench.files.action.showActiveFileInExplorer as well so I can get to a random file in the explorer if I need to.

@Tyriar I'm not sure which version you're referring to but I'm up to date on Insider and that option doesn't do anything yet.

:+1:

:+1:

@bpasero I have read the first few messages on this board regarding the advantages/disadvantages of tabs. I also understand MSFT Team stance at this: the team is united under the same coding style and developed the same set of reflexes regarding ctrl+tab and/or the working files section. That is a good thing. All the team members having uniform flow of doing things, in general. However, we are not part of that team, nor we wish to develop the same set of reflexes. Our existing reflexes should, ideally, be fulfilled, not forced out and replaced. The editor should help the user.

We will have to either adapt to your definition of UX, or stop using VSCode. Some will adapt, some will not. Is all about the balance between good and bad things put on the table. That being said, I think the MSFT team greatly underestimates the importance of tabs, and greatly overestimates the in-the-house developed reflexes.

The team and the people in charge really need to make one simple decision: is VS Code a Human-Computer-Interaction experiment or is it supposed to be a solid, usable IDE that _gives developers what they want?_ If the former, that's OK. Personally, I'll stop bothering and move elsewhere because I want to get my work done, not be part of a HCI experiment, but I'm sure that their experiment will pay dividends down the line. If the latter, they need to implement tabs, at least, because that's what developers want, and _both_ tabs and no-tabs at best if they want to chase both rabbits and try and convert people to a new workflow.

@Tyriar: I tried your autoReveal setting in v.1.0.0-insider and it did nothing for me, either. The explorer still jumps about when I don't want it to - most irritatingly, when it scrolls completely to a different place when I use go-to-definition and that opens another file.

This is what I put in my preferences file: "explorer.autoReveal": false,

@anyong @stephenmartindale you're right, I didn't realize how new this setting was. It should be available on the next Insiders build.

Well said @stephenmartindale. Without tabs all we have is notepad.exe with its own version of Alt-Tab (which as noted many time above, is broken). I've been trying to use "Working Files" as if they were side tabs, but after a week I'm pretty much ready to go back to Sublime and it's issues, particularly that there's no way to make that sidebar always be there no matter what else is going on in the app. With the name "Visual Studio..." I expected at least the basic features of the Visual Studio editor (tabs, and the ability to drag those tabs into their own windows). Why they would have removed that functionality is unexplainable. Maybe I'll check back in a few months and see if they've gotten far enough to put a pre-alpha tag on a build. Right now this is nothing more than a UI experiment, the only question is has it already failed or is it teetering on the brink of failure?

As most of the previous 259 comments have stated, I would very much like to see tabs in VS Code, similar to how they operate in Sublime Text. I, too, would gladly switch if it weren't for this one missing feature. As strange as it sounds, I do need the ability to have at least four documents open in the same window so I can switch between them rapidly.

Oh, and if Microsoft doesn't want VS Code to be compared Sublime Text so much, then they shouldn't have made a product that looks and acts so similar to it. Keeping tabs away from the GUI isn't a way to discourage comparisons to Sublime Text; it's a way to make those comparisons less favorable for Microsoft.

@SturmB Sublime is not the only editor that exists and I don't think they made VSCode to be yet another Sublime copycat, much like Atom isn't Sublime but all editors are sharing features which is a good thing, that's how you get choices!

VSCode isn't acting like Sublime at all because they are very different, VSCode aims to be the middle ground between a code editor and an IDE whereas Sublime doesn't make that claim, therefor, VSCode have larger audience of people, ranging from people that use Vim to Visual Studio.

Adding tabs is not the problem at all, people keep on saying that they need to add tabs and I'm sure that by now they understand that tabs are important but the real problem is getting the design right and make sure the experience feels great for everyone, these who love tabs and these who hate it.

Now, when you design a feature, especially a feature that is core to the experience in the editor, you can't just hack few things and put them together and then come back with an announcement that after few days will get many people disappointed! good things takes time! and this isn't different. :)

I like the working files concept. Tabs don't scale well when many files are open. Whatever happens, please keep the working files control!

@helmbold I am genuinely curious - _how_ do you use them efficiently? I've _tried_ and I just cant figure out how to make sense of the mess that is WF. (Also, somewhere way up in this issue, the team said that working files was really just an afterthought, not a planned feature.)

@eyalsk:

the real problem is getting the design right and make sure the experience feels great for everyone, these who love tabs and these who hate it.

Pretty much everyone here has said they hope the tabs will be controlled by a setting for exactly this reason. That being said, while some software during early iterations of tabs years ago wasn't very nice to use, these days it's usually pretty good. Code has Sublime, Atom, and non-editors like browsers to look to for making tabs "right."

One feature I'd like to see that I haven't seen in any tabbed software and that I think would alleviate some issues with "too many tabs" is a way to select and drag multiple tabs out into a new window.

At the end of the day, human-computer interfaces for managing hundreds of files with long similar-looking names are always going to be lacking - that's not how we are designed to work, it's just how we're forced to work because of the current state of software engineering.

@anyong sure! adding options isn't a problem at all, I mean the problem starts when you're asking yourself what options are redundant and what options are actually useful, programs that were designed with tabs in mind from the get go have it really easy for multiple reasons but mainly because tabs isn't an afterthought, also, it's not possible to compare one editor to another or even to another program that has tabs mainly because the navigation story is generally different from program to program, different programs aim to focus on different things.

Just because Sublime/Atom or another program has tabs and it works well there doesn't mean you can take all the things that work there and bake it into your program, that's not how things work, in fact that's how things _can_ fail! it's successful there because the whole package makes it successful.

Now, adding a new kind of user experience to the editor kinda require you to re-evaluate the whole navigation story including existing features like "working files", especially when you have existing consumers where each person expects it to work like their editor of choice and you can tell from the posts that many of them have high standards to how it should work. :)

:+1:

@bpasero, @bgashler1 and I have started working on the UX designs for improving document management. We're watching all the feedback on this issue carefully and have spoken to a handful of you already to get more details about your own unique experiences and perspective.

We would now like to share our early designs with you to get your feedback. We will host a Google hangout on Thursday 21st April at 4pm BST. If you want to join us, please click this link at that time: https://hangouts.google.com/call/u3wnrhjja5h47ovt7piatelkxme

This will be our first public design meeting and we're looking forward to it.

I have been using VSCode exclusively (came from WebStorm) and I haven't been missing tabs. Initially I thought that I would, but I started to like Working Files more since I could see more in less space and without having to think about how to arrange or group things on screen. Now I use CTRL+TAB primarily.

I think if anything traditional tabs should be an official _extension_ or an opt-in _option_. Personally I am hoping for something other than tabs to enhance the current experience.

What I find that CTRL+TAB lacks is the context of the active editor pane. If I have 2 editor panes open side-by-side then I would like to see CTRL+TAB show the file history filtered down to files that have been opened in the active editor pane rather than all files opened in the application as a whole (although that would still need to exist as well). Also, perhaps clicking the somewhere on/near the filename at the top of an editor pane could display a drop list of files opened in that editor pane (same as CTRL+TAB).

Keep up the good work.

One other suggestion.. It would be nice to have a better default key combo to view the list of Working Files for when the sidebar is hidden. I just recently discovered that CTRL+K CTRL+P shows what I want but it's more difficult to pull up than CTRL+TAB. Like I suggested with CTRL+TAB, the Working Files popup could benefit from some context based on the active editor pane. Maybe it could be sorted so that the list of Working Files that have been opened in the active editor pane are above the rest.

@RyanEwen I guess you're not a shortcut user before? Because Intellij Idea platform has same shortcuts and able to place the Tabs anywhere (Top, Bottom, Left, Right, None). When it placed on Left / Right, it works similar to Working Files in VSCode. It would be great to do some experiment. Going back to WebStorm using CTRL + TAB combo with top Tabs to see if you don't need it or being forced to accept it as the only workaround. CTRL + E in WebStorm also a Recent Files with filtering (type to search) features.

Anyone said no to Tabs please also mention if you were using MOUSE in your workflow.

:+1:

@KayLeung I have used CTRL+E in WebStorm, but since there were tabs I would allow myself to go for them using the mouse more often than not. I recently used a tabbed editor (Koding.io) when I didn't have access to VSCode and can confidentially say that I don't miss setting up/arranging tabs. It seems tedious compared to just having a history. I found myself always get caught-up in how I want things laid out and predicting what files to open rather than just using the editor and flipping between files. This is probably partially a "me" problem more than a tab problem, I know. A little bit OCD, I guess.

I was a mouser when I used WebStorm. I used key shortcuts to search for recent and unopened files here and there, but moused to tabs for what was already opened. I didn't feel I could keyboard to specific tabs easily/intuitively, and there was that desire to arrange the tabs which also caused me to reach for my mouse in the end. Having a lack of tabs has unconsciously (and painlessly - in my case) helped me to slip into a keyboard-first workflow.

I just tried Adobe Brackets, and their Working Files list is split up by pane. If you have a Left and a Right pane then there are 2 lists of working files ("Left" and "Right") in the sidebar instead of one as in VSCode. Not a bad solution. Wouldn't mind something like that (in addition to my other suggestion of adding context to CTRL+TAB based on the active editor pane).

@RyanEwen you have made a very good point. I always work with 2 panes for any open instance of my IDE. I may have 2 open instances over 2 screens, for 4 open panes. I couldn't quite put my finger on it but you did. Having a single list when there are two (or more?) open panes, is the problem with current the Working Files implementation that has made it unusable for me. Thank you for being specific here.

A friendly reminder that we (myself, @bpasero and @bgashler1) will be sharing our latest designs for tabs and working files later today at 4pm British Summer Time.

Join us on this link at 4pm BST: https://hangouts.google.com/call/u3wnrhjja5h47ovt7piatelkxme. We would love to hear your feedback.

Reminder for anyone who was planning to join the hangouts - it's on now so click the link above. Only ~5 people so far.

I would have really liked to be there but it's 11am and I'm at work unable to join. I assume someone will have some stuff to share in writing afterwards? :D

Brief overview:

1. Tabs and working files (renamed "open editors") behave exactly the same way, it just depends whether you want the visuals on top (tabs) or to the left (open editors)
2. Tabs are grouped by panel visually at the top, open editors are grouped together under headers "Left", "Right"
3. Single click a file to open a preview tab (or "open editor"); double-click the file, edit the file, or double-click the tab itself to persist
4. Debugger opens all files as preview files unless you persist the file being debugged by taking one of the above options
5. Tabs/open editors can be dragged between panels
6. Panels can be dragged to move the whole group of tabs

Looks really good, and personally (from the very pro-tab group if you read my post above), I think I will be happy to give the new "Open Editors" a fair shot.

Followup thoughts for the devs:

1. Since the tabs/open editors flow is exactly the same, it should be possible to do something like this: show open editors when the explorer is open, and show tabs when the explorer is closed. We can increase horizontal real estate for code and maintain tab access. Assuming there is a hide/show tabs shortcut, this would be the equivalent of pressing that and CTRL+B at the same time - if it works, it should be an option in the settings: autoShowTabsWhenExplorerClosed or something. If we need to see more tabs, we can either click the chevron, or simply CTRL+B to see the tabs over in the left panel. I'm not sure if that would be "disorienting" at all, but as long as the open editors and tabs are always exactly the same and in the same order, I can imagine that it would work very well.
2. I think you mentioned that previously closed tabs were available in one of the CTRL+Tab+something views, but have you thought about a CTRL+SHIFT+T (undo close tab) shortcut that would simply reopen previously closed tabs (in the order in which they were closed)?

I was only able to join for the last 15 minutes or so. Was it recorded?

I was disappointed (but not surprised) to see that tabs are likely to
become the default. A hope you will continue to preserve the lightweight
environment of VS Code and to explore progressive workflows.

Thanks,

James

On Thu, Apr 21, 2016 at 11:07 AM, anyong [email protected] wrote:

Reminder for anyone who was planning to join the hangouts - it's on now so
click the link above. Only ~5 people so far.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-212963079

Sounds like there were some good ideas. I look forward to seeing this in action.

FWIW (and if it's still relevant) I still think it's better not to have tabs in the UI _by default_. A nice clean editor header that can be clicked to see a list of files if I don't have the sidebar visible, or CTRL+TAB, is what I'm really hoping for :)

Thanks for everyone who was able to attend and give us feedback today. We've taken notes and have been continuously following the GitHub issue here. We're listening to everyone.

@indiejames and @RyanEwen yes we took notes, and we will be posting soon. We have not decided for sure on the default behavior yet. However, we are proposing a solution that would make it easy to choose whether or not you want to use working files, tabs or both.

@bgashler1 you mention that you're looking into a solution that will allow people to choose whether they want the working files, tabs or both what about none? is that an option? depends on the project and language I'm working on none can be great for scripting like PowerShell. :)

Thanks to everyone who took the time to join the call today and provide feedback, we really appreciate it. @anyong has done a great job already summarising what we presented but I will add a few more details below and some screenshots.

Visual design

First, this image indicates how we think tabs might look in VS Code:

We are aiming for a lightweight, non distracting look, something that fits in well with the rest of VS Code. We haven't yet drawn up what it would look like in a light theme.

As you can see in the above image, tabs contain a close button to the left of the name. When the file contains unsaved changes we show a dirty indicator where the close button is.

Hovering over a tab will show a tooltip with the full path for the file in the tab.

Preview tabs

To clearly distinguish preview tabs from open tabs we italicize the title in the tab as in the following wireframe.

We discussed actions for promoting a preview tab to a full open tab:

• Editing content inside the tab
• Double clicking a file in the explorer
• Double clicking the preview tab in the tab group

Overflow

Tabs open to the right of the active tab. If there is not enough room to show all of the tabs in a tab group we overflow the tabs. We do not truncate the name of the file inside the tab to make more room for more tabs.

We show a chevron whenever there is an overflow. Clicking on that chevron will show a quick open dialog that lists all of the tabs in the tab group, allowing the user to find the tab they want to view.

Clicking a tab that is currently in overflow will bring that tab into view.

Navigating tabs

The following commands allow users to navigate amongst tabs:

• Ctrl-Tab shows a list of all tabs inside the active tab group:
  
• Ctrl Alt Tab shows a list of all tabs inside all tab groups
  
• Quick open shows the linear history of all tabs
  

Working files

We renamed working files to open editors to better reflect what this really is.

The list of open editors works identically to tabs. We just list them in the explorer rather than visualising them as tabs.

If a file is open in two or more editor groups we show this in the open editors list:

Any editor that the user opens shows up in the open editors list. So for example, the diff editor shows up like so:

Each group only contains one preview tab.

The chevron at the top right of the active editor group indicates whether or not there is a stack of editors.

In this case, closing an editor will reveal the editor below it in the stack, rather than closing the editor completely.

Closing an editor (for example with Ctrl-W) also removes the editor from the list of open editors.

@stevencl

To clearly distinguish preview tabs from open tabs we italicize the title in the tab as in the following wireframe.

In addition to italicize it, it can be great if there was an option to dim the colors of the tabs to make it _really_ clear.

As I wrote before I'd also want to know whether there's an option to have no tabs or open editors at all, this can be useful scenario for people that do scripting e.g. PowerShell.

@eyalsk it was mentioned in the discussion that tabs and open editors should be independently enabled or disabled for either/both/none.

@anyong thanks! :)

Ctrl-Tab shows a list of all tabs inside the active tab group:

Finally! Tabs or not, this is the behaviour I've been waiting for! No more getting lost in my file history.

Closing an editor (for example with Ctrl-W) also removes the editor from the list of open editors.

Great! This will hopefully feel more intuitive and help clean up the clutter in _Working files_.

Now I'll just wait for https://github.com/Microsoft/vscode/issues/5554 to close.

Hmm I don't know whether this was considered but I thought about it just now, multiple monitors suppot! in Visual Studio I can drag a tab to a different monitor and create a new tab window/view, is something like this being considered? I'd imagine it's possible to achieve this by creating a new VSCode process and drag tabs between processes through inter-process communication, the same goes for open editors, just an idea, :)

Please, please, please can you make "preview tabs" optional - i.e. have an option to make anything auto-promote to a permanent tab and never have stuff disappearing. I know you're discussing ways to visually distinguish tabs that are temporary but, frankly, that won't work for people like me who navigate between files so quickly (particularly with Go-To-Definition et al.) that there's no time to visually inspect the tab to divine how it might behave, I don't remember how I opened a file or whether I happen to have edited it and I find it really disconcerting when files vanish seemingly at random. (I know it isn't random but it might as well be.)

I typically bury myself in open tabs until I have finished a unit of work and then close them all at the same time that I go to commit.

Thanks @eyalsk, yes we did consider it. Ultimately we would like to be able to support this but the work required to share context between multiple processes is quite significant and so it is unlikely to happen while we work on the rest of the document management UX. It's definitely something we want to do though.

@stevencl I'd be happy if dragging just opened a new vscode window with that file open (maybe with the same folder open too).

Thanks @Tyriar, we will keep looking into this. If there is a way we can make it work well, we'd love to be able to do it.

@stevencl I'm just worried that it will require even more work to add it in the future so _when_ you improve the infrastructure make sure to keep it in your backlogs! ;)

tabs please

Great to see this. Love the lightweight proposal and that you are finding a way to not break the working files experience.

Looking forward to giving it a spin. Thanks for listening.

@stevencl That seems like the best of both worlds. Looks wonderful! The tabs appear as I would have expected them to in order to fit in with the rest of the UI, and it sounds like I'd be getting exactly what I want with the Working Files changes :)

Will Open Editors support more than 2 editor groups? Just wondering how you name them if it's more complicated than Left and Right.

Yes, this would still be supported.

From: Maxime Quandallemailto:[email protected]
Sent: ‎22/‎04/‎2016 23:09
To: Microsoft/vscodemailto:[email protected]
Cc: Steven Clarkemailto:[email protected]; Mentionmailto:[email protected]
Subject: Re: [Microsoft/vscode] Proper tabs for open files (#224)

Would panes repositioning by drag&drop would still be possible under the @stevencl proposal?

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/Microsoft/vscode/issues/224#issuecomment-213605667

@stevencl I think what you outlined from the discussion a few days ago is great. This is exactly what we all have been waiting for regarding tabs. A few of the other editors I have use also implement horizontal as well as vertical panel configurations. This allows you to have two files opened side by side at the top and one or two opened below them. While this is a not a critical feature, I do find myself missing this quite often while developing front end web apps & mobile apps. The reason is most of what I work on is MVC or derivations thereof so having a model, view, controller and some UI file (css, Js, etc) open at the same time is a huge benefit. Are there plans to include this as well? Atom does this really well which was the last editor I used before VSCode. Unfortunately it severely lacked in other areas that VSCode excels at, hence my sole use of VSCode. If not in the planned release with tabs & document management changes, this would be a great future enhancement.

@jayrosen1576 horizontal splitting is captured in this issue https://github.com/Microsoft/vscode/issues/1749, be sure to :+1: to show your interest.

Good work guys the wire frames look like they would work really well.

Hey @stevencl
Thanks for the great work and here is my 2 cents about the close button to the left.
When there are many files open and the tabs are getting shrinked, the small space for each tab will only be enough to show the close button which will make it easier to accidentally close the tab instead of selecting it.

Dirty indicator icon can still stay on the left since it does only indicate file status, but moving close button to the right will let us easily recognise the filename and will prevent accidental close action.

@stevencl Mock-ups look great and description of functionality sounds spot-on. My initial impression though, is that the tabs are kinda big... perhaps bigger than they need to be, and appear to waste some space. I understand the trade-off between stylish presentation and functionality, but this is a dev tool, practical design trumps style for sure. I'm sure you've experimented with this calibration however, so I look forward to trying it out!

@hsyn it was my understanding that the tabs will not shrink, and overflow tabs will be available from the chevron overflow button. The close button shouldnt be an issue.

Tabs open to the right of the active tab. If there is not enough room to show all of the tabs in a tab group we overflow the tabs. We do not truncate the name of the file inside the tab to make more room for more tabs.

I don't agree with that. If the screen is split into 2-3 columns, you will then be showing 1-2 tabs at most and overflowing the rest. Please, please do what browsers do, we use them every day and it's intuitive and we are used to it. I encourage you to use established patterns, some of them have been evolving for over a decade now. Don't go against the grain.

I don't agree with that. If the screen is split into 2-3 columns, you will then be showing 1-2 tabs at most and overflowing the rest. Please, please do what browsers do, we use them every day and it's intuitive and we are used to it. I encourage you to use established patterns, some of them have been evolving for over a decade now. Don't go against the grain.

Some browsers do a combination of shrinking tabs but then overflowing them beyond a certain threshold. Firefox does it; pretty sure iOS Safari does (or did) it too.

When enough tabs are open that you can barely see a few letters in each one (though in practice I normally don't have that many open), it's not particularly more usable than overflow would be.

@alexgorbatchev I definitely get where you're coming from, but this was something they explained in the conference call the other day - from the other perspective, having a ton of opened tabs and not being able to read the names of any of them is not a good solution either. The "overflow" is sort of a compromise between no tabs at all and standard "Chrome style" tabs that shrink into oblivion. Forcing the tabs to at least display the filenames means that the visible tabs will at least be useful.

But you did give me an idea though for the devs - I think the real issue here is that, while we know we cant use 20 tabs when all the filenames are hidden, at least we _know_ that there are 20 tabs open and it provides us a certain feeling of "I know where my files are if I need them, they didn't just disappear." All it would take to fix that is an indicator showing the _number_ of currently hidden tabs, the indicator could just be a little circle above the overflow chevron so as not to take up any extra horizontal space.

Thanks everyone. We didn't show it in the mockups but our intention is that when required, we will shrink the tabs so that only the name of the file and the close button are visible. For the reasons @anyong mentions, we don't think we want to shrink to the point where filenames aren't distinguishable from one another. We think that it is probably more common for multiple tabs in a code editor to have similar names than it is for browser tabs to have similar names (e.g., there could be many filenames with the same prefix). Thus we think that shrinking tabs in a code editor has different consequences than in a browser.

We intend to show when tabs are in the overflow control with the double chevron but placing a badge with the number of overflowing tabs is an interesting idea too. Is the intent that the number simply indicates that there are overflow tabs or is the actual number of overflow tabs important?

Thanks for clearing it up @stevencl.

One edge case to keep in mind with file names in tabs is multiple files with the same name opened from different folders (index.js, README, LICENSE, package.json, etc).

I probably won't be using tabs at all, but I think it's also worth pointing
out that browsers usually display the favicon for a site in the tab which
makes it easier to identify even when the tab shrinks beyond the point that
it's readable. Source files would not have a favicon to disambiguate them,
and, as Steven points out, file names are often similar in source code.

On Thu, Apr 28, 2016 at 12:16 PM, Steven Clarke [email protected]
wrote:

Thanks everyone. We didn't show it in the mockups but our intention is
that when required, we will shrink the tabs so that only the name of the
file and the close button are visible. For the reasons @anyong
https://github.com/anyong mentions, we don't think we want to shrink to
the point where filenames aren't distinguishable from one another. We think
that it is probably more common for multiple tabs in a code editor to have
similar names than it is for browser tabs to have similar names (e.g.,
there could be many filenames with the same prefix). Thus we think that
shrinking tabs in a code editor has different consequences than in a
browser.

We intend to show when tabs are in the overflow control with the double
chevron but placing a badge with the number of overflowing tabs is an
interesting idea too. Is the intent that the number simply indicates that
there are overflow tabs or is the actual number of overflow tabs important?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-215481474

Thanks @alexgorbatchev. We have a few ideas for how to show the path to a file to be able to disambiguate in these cases. In the high fidelity mockup shown above for example we show the path to the file underneath the file name. This is just one idea though and might not work when the path is long. Another would be to put the path in the status bar. Lots of things to explore...

@stevencl

Is the intent that the number simply indicates that there are overflow tabs or is the actual number of overflow tabs important?

I would think showing the actual number of tabs open (but hidden from view) would solve the problem. Essentially, people are used to seeing this (well, speaking for myself at least):

so they intuitively have some idea of "I've got a lot of tabs open" vs. "I've got 2 or 3 tabs open"

A badge showing "20" is a lot smaller (no extra real estate, essentially) than showing 20 tiny/useless shrunken tabs, but it still allows me to know immediately that (a) the hidden tabs are there and (b) exactly how many there are.

I'm only new to this thread but my 2p as a full VS2015 user:

Looking forward to having tabs in vscode, as working files never fit with me (though I now see that hitting ctrl-f4 does not remove from that set as I had assumed it did).

Big fan of preview tab, glad to see it coming in.

Curious as to why new tabs will open to the right of active tab. I expect 'because web browsers' or 'because sublime' is the answer, but it seems counterintuitive to me, especially if tabs overflow by hiding from the left (into the chevron at the right).

I'm hoping to see right click menus for tabs as per VS... 'Close all' (for group) most importantly, not fussed about 'Close all except this'. A VS style save box for all modified files would be useful here.

The close button on the left is odd to me - I assume it is some mac/linux convention - but as long as 'middle button click' on tab closes an editor (prompt to save if applicable), then no bother. I can see why it is on left to rapidly close a bunch of files in succession, but middle click is better for that anyway (though maybe not for macs or notebooks with no scrollwheel?).

Chevron file picker should allow typing for quick jump to a file. Not that I personally plan to have enough files open to display the chevron, (and when I do I will no doubt use ctrl-p) but it happens.

Chevron number - is this a count of _hidden_ tabs/files/editors in this group, or a count of _all_ including visible files? I would argue only the hidden items, especially if you only show the chevron (and thus the count) when something overflows off the tab row.

On a slightly related note, if I ctrl-f4 (or ctrl-w? It seems to be the non-windows version of ctrl-f4 unless I am mistaken), I expect that if the tab is going away, it is closing the editor and should prompt for save/discard and remove it from ctrl-tab/ctrl-alt-tab/working files... I can see there is some keybind change I can do at the moment for enabling this functionality, but I struggle to see why in a tab based interface the existence of a tab is not directly related to the 'current'-/open-ness of the file/editor.

Loving what you all are doing on vscode, it's looking amazing ☺

I tried out using the file history as suggested, and after a month I don't feel like I need tabs anymore. In VS having a bunch of tabs open is really annoying. I hate it when there are too many and get moved into the little dropdown of hidden tabs. I think I would actually really like to use file history in VS now too.

Regarding the working files, I find it really annoying that everything is in there. It's annoying to the point that I never open it and keep it closed. The only thing I find it useful for is seeing new files that haven't been saved, or any file that hasn't been saved I guess. It quickly gets too large for me to even care about. Not sure how this could be fixed though. Maybe only show unsaved files, but that would have some weird side effects.

Anyways, I'm a file history believer now. :)

I think it would be really cool if we could add the ability to go back and forth in the history using shift+cmd+[ and shift+cmd+]. these are the default shortcuts for navigating around tabs in other applications and being able to use them to navigate the history instead I think would go a long way towards making me a believer at least

Edit: basically achieved this by implementing

  { "key": "shift+cmd+[", "command": "workbench.action.openPreviousEditor" },
  { "key": "shift+cmd+]", "command": "workbench.action.openPreviousEditor" },
  { "key": "shift+cmd+[", "command": "workbench.action.quickOpenNavigateNext", "when": "inQuickOpen" },
  { "key": "shift+cmd+]", "command": "workbench.action.quickOpenNavigatePrevious", "when": "inQuickOpen" }

as custom key bindings

Being able to tear out a code section into a new window would be useful I think too. Not sure if that thing is even possible though.

@JoshClose it's totally possible but they lack the infrastructure for inter-process communication for the editor itself so for two instances to communicate and do anything they need to have a protocol for this first.

... tabs contain a close button to the left of the name

Is there a specific reason for breaking convention? When reading LTR, the most important piece of information is the file name, not a close button. Moving it to the right would also make it easier to make the close buttons hidden by default (and displayed on hover). At a later stage, users may also want to have file icons to the left of the file name.

We discussed actions for promoting a preview tab to a full open tab ...

I think the first two options would probably be sufficient. Double-clicking a tab may be useful for other things in future.

We have a few ideas for how to show the path to a file to be able to disambiguate in these cases.

What about simply showing a tooltip (with the relative path) when hovering over a tab? This would make the design less cluttered, and the tabs would not have to be as tall.

We show a chevron whenever there is an overflow ...

Firefox handles tab overflow well – it has max tab width, left/right scroll buttons, drop-menu listing all tabs (with the currently-visible tabs marked), etc.

Would be really nice if the tab close buttons matched the platform conventions: On the left on OS X, on the right on Windows.

After using VSCode for some time now, I think the _Working Files_ mode has grown on me, a lot!

Here are a few reasons:

1. Although it sounds counter-intuitive, closing a file I'm not using (ctrl-w) does not take it out of the Working Files. This is very good because many times I find myself re-opening recently closed files (in a React project) when working with related files (or children classes). So, when I _feel_ like I should close a file does not map one-to-one to the time when I _should_ have closed it.
2. I like the explicit Force-Close, which is offered by the workbench.files.action.closeFile.
3. I've remapped workbench.files.action.closeFile to Ctrl+k Ctrl+w because it requires (slightly) lesser effort than Ctrl+k w,
4. I can see the full file name and path in the top bar of the editor -> This is very important in deeply nested projects (like I have) which has files with similar or same names (index.js?) and only way to differentiate is by path.
5. Less noise of tabs = Zen!

So, in a way I'm trying to say that please _don't remove_ the current flow if you introduce the tabs thing.

@kumarharsh why would they remove that? if anything they will probably improve it for you! :)

If the dirty indicator replaces the CLOSE icon, how will we be able to close the file if we don't want to save our changes? Will ctrl-w still be available?

Couldn't the dirty indicator just change to the close button on hover?
That's a pretty common solution...

On Wed, May 4, 2016 at 11:28 PM, rojorojo [email protected] wrote:

If the dirty indicator replaces the CLOSE icon, how will we be able to
close the file if we don't want to save our changes? Will ctrl-w still be
available?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-216901750

@rojorojo we are doing what @anyong also suggested, so you won't have any trouble. And yes, Ctrl+W will be still available.

Thanks for all the feedback.

We're running a UX study on our latest designs at the end of this month. If you can spare an hour on 25th or 26th May and would like to participate in the study, please sign up here: https://calendly.com/stevencl/vs-code-docmgmt/

Unfortunately I can only offer times during the day (British Summer Time) and can't run sessions in the evening.

We are hoping to have some working bits that you can try out, as well as some design wireframes that we haven't shown yet.

Wait, I love the current UI behavior, will there be a configuration?

Three weeks ago I really wanted tabs. I even put off switching to VSC for a while since it didn't have tabs. Now that I've spent a couple weeks using VSC, I don't even want tabs. At this point I think they'd get in my way.

I hope when this is built it will be optional so those of us who want it can continue in the current environment.

As someone who really likes vertical tabs (they scale much better and work better on widescreen displays), I’m wondering: Why do you need both tabs and “open editors”. If the latter is basically “working files” with tab behavior then that’s all I’d need/want.

I want to add my vote to making sure the tabs are optional. I really dislike editor tabs and much prefer the panel on the left side of the window. I understand adding them for the people who want them, but please, don't force them on us. Not having them is one of the things I _like_ about this editor.

My two cents: I don't ever want close buttons; to me, they're a waste of real estate that sometimes cause frustration (accidentally click). It's much more difficult to accidentally middle-click than to accidentally click 1px too far to the left.

I also think dirty indicators are a waste of real estate. In Sublime Text, I configure "dirty" to just change the tab's font color. In the past, I've also made it italicized but it sounds like you have plans for italicizing previews.

The left side of the border is too wide

@be5invis @MrTravisB @rauschma @marcusrugger @jpaaso

Folks I understand that it's a long thread so you probably didn't read it all, but please read the posts around here. Tabs will be optional, the devs are already very, very aware of the points you are bringing up.

Would-be posters: please look through the thread to see if your issues are already addressed - every time you post there are a hundred people getting emails with your :+1: Thanks

@anyong However the “Open editor” separates the existing working file list into two half if you open two columns. I love the idea that there is only one “working files” for all editor columns.
Please make this optional either.

@be5invis The only difference is that there is a visual separator. You can still drag the files around and open them in any editor you like.

@anyong Can I hide it? And if I choose to hide the "separator", and Ctrl-Tab in one editor column, can I switch to a open file in the other column? What the con-tabbers want is to completely maintain the existing behavior.

@be5invis from the comment I linked to above:

Ctrl Alt Tab shows a list of all tabs inside all tab groups

So yes, you can still set the key binding to keep the current Ctrl+Tab behavior if you want.

@anyong That's good.
But still, can I hide the “left/right” indicator and make the list looks like a unity?

That would be a question for @stevencl

Yay! I hope we get tabs soon!

Great News ..we are Getting Tabs..But we don't want to loose 'Working Files' Folder .Keep it along with tabs ?

Awesome! Tab Groups

@be5invis You're right, we intend to show multiple editor groups in the open editors list once you split the editor. But you don't need to do this in order to be able to work with multiple files. You would split the editor to view more than once file at once. If you just keep one editor visible at any time you can still have multiple files open. For example, in this screenshot

I have two files open but I'm only viewing one of them since I haven't split the editor. The open editors list shows both the files and I can interact with them there or through the overflow control on the top right. (And note that there are no tabs shown here - this is the no tabs option.)

The reason we have done this is that there is the potential for confusion when managing a file that is open in two editors in the current working files setup. For example, in the screenshot below from the current product, what should happen when I close file app.js in the working files list. Should both editors close or just one of them. And if just one of them, which one?

We want to avoid any ambiguity and uncertainty so we have opted to be more explicit about the files that are open in each editor group.

That's also why we renamed working files to open editors as we feel that better reflects the new behaviour.

Go To Definition(F12) option need to be enhanced (Even the Definition one is in another page with in the project))like sublime text?i'm facing this issue from long since i install VS code ?Any help on this?

@vinod-a-ext - please open a new issue describing the problem you are facing with Go To Definition.

@stevencl
Go to Definition Problem in VS Code
https://github.com/Microsoft/vscode/issues/6238

@stevencl My opinion is that you can hide the labels in the “open editor”, and simply draw a line to represent different panels. Once a panel is closed, then two lists can be merged naturally.

Thanks for the suggestion, we'll definitely explore different visual treatments for this.

Date: Tue, 10 May 2016 04:06:34 -0700
From: [email protected]
To: [email protected]
CC: [email protected]; [email protected]
Subject: Re: [Microsoft/vscode] Proper tabs for open files (#224)

@stevencl My opinion is that you can hide the labels in the “open editor”, and simply draw a line to represent different panels. Once a panel is closed, then two lists can be merged naturally.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

I'm curious, what program did you use to generate the mock ups, like this one

We used PowerPoint for these mockups. Our intent was to focus on the interaction flow, not the visual design so the tools in PowerPoint work fine for that level of detail. Doing things in PowerPoint also allows us to easily string together a sequence of screens to get a better feel for the flow.

Date: Tue, 10 May 2016 05:03:55 -0700
From: [email protected]
To: [email protected]
CC: [email protected]; [email protected]
Subject: Re: [Microsoft/vscode] Proper tabs for open files (#224)

I'm curious, what program did you use to generate the mock ups, like this one

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

Just came here after seeing April release notes. Thread open for a long time - but I am +1 for the original design - i.e. no tabs. Initially it bothered me - but then I grew to appreciate and understand the philosophy behind it... Now when I think of Atom and the tab spam... I shiver. All that aside - I love the engagement and thoughtful comments and feedback from the developers.

Looking forward to trying this out. One thing I'd love to see is combining of multiple related files into a single tab (similar to this VS plugin)

This would be really useful for keeping organised in Angular 2 development, where you commonly have related files:

• widget.component.css
• widget.component.html
• widget.component.ts
• widget.component.spec.ts

Agreed with @lucidtech we used to 'working Files' Folder .I think tabs can combine along with this great option?

I agree with @coreh that the location of the close tab button should match platform conventions. It would be a rather frustrating context switch to have the location of the close button change when I move from Visual Studio to Visual Studio Code.

My two cents: One reason why I _love_ Code over Atom, Sublime, or any of the other, ahem, hipster editors is that it doesn't try to shoe-horn in the web browser "tab" concept. The traditional IDEs such as Visual Studio, IDEA, and Eclipse all do this too. Code, on the other hand, has a "frames and buffers" approach, akin to what you'd find in Emacs (and Vim, too, I believe).

Inevitably, in any tab-based editor I find myself obliged to work with results in my editor frames being horribly spammed with tabs for which the folder fobs are so tiny they're unreadable. Furthermore, when I use such an editor's equivalent to Ctrl/⌘-P I end up warping to another frame as an artifact of whichever frame I was looking at when I first navigated to the file. In order to view the the same file in another frame, you have to do a clunky "split tab" operation which also often tends to be coupled with splitting frames in many of these editors. _Tabs tightly couple file buffer state with a given frame on the display._

If you'll excuse the emotional appeal, please _please_ don't turn VS Code into yet another tabbed editor.

I think, from a UX perspective, rather than blindly implementing tabs to match the behaviour of Atom or any other editor, it would be instructive to figure out _why_ people want tabs (other than just comfortable familiarity) and see if a more innovative solution to their needs is possible. I certainly agree the current workspace regime can continue to evolve: as someone else has mentioned opening a separate window in the same (equivalent to tab-based "ripout") project in order to better leverage multi-head displays come to mind!

edit: very sad that I missed the call 19 days ago. I would have joined if I had known about it. Only found out from the release notes of 1.1.0. :(

Tabs are a must for me and another suggestion for e.g. angular 2.0 grouped tabs for related files is a great idea too. If the feature is configurable then those whose preference differs will be happy too. When can we try!!!???

@orospakr, you can turn off the tabs in Sublime through a menu option. Just FYI.

@orospakr

it would be instructive to figure out why people want tabs (other than just comfortable familiarity) and see if a more innovative solution to their needs is possible.

There's a ton of feedback about why people want tabs aside of familiarity, not to mention that if it's familiar and people are comfortable with it then it doesn't make sense to get creative and innovate something where there's already something that works.

They tried to innovate with the "working files" and one group liked it, the other disliked it and here we are today asking for tabs! I don't think that you want the same syndrome to happen again...

The right way to do it is to get the experience people are looking for first and then have additional features, innovation or experiments during alpha builds and/or as an option.

In this case of tabs/"open editors" or tomorrow something else they made it optional and that's how it should be people need to have the ability to opt-in to the experience or opt-out from it.

I know that I am a little late to the game here, but in regards to this section:

We discussed actions for promoting a preview tab to a full open tab:

Editing content inside the tab
Double clicking a file in the explorer
Double clicking the preview tab in the tab group

I would like to request that "Adding a bookmark" be included in the above list.
I find it extremely frustrating to add a bookmark to a large file and then inadvertently click on another file, closing the working file.

It's very unlikely that I have added a bookmark to a file that I intend to close immediately.

looked over as many comments as I could, searching for keywords and didn't find this mentioned.

as far as tabs go, firstly, _thank you!_ their absence is one of the only things I dislike about VS Code.

I would love to see navigation between tabs be customizable; for example, I love the way iTerm switches between tabs by pressing cmd + left, and would very much so like to do this in my editor as well.

thank you for a great editor <3

Tabs are a must for me... Switching back to Sublime until you have tabs. P.S. I am very disappointed at your attitude; You seems to have no sense of UX yet claiming this has been done to improve UX. What are your personas? Where are your user interviews? Prove it.

@asadighi did you even a read the comments before posting? The team has done extensive interviews and are conducting more to get tabs right. They are incredibly responsive to the community and are producing a great editor (for free). Good luck waiting for the next release of Sublime.

Your previous comments are telling of your bias. My objection is on the attitude they have had from the get go. User interviews should happen BEFORE people start bashing the product for such flaw. Interesting enough you can see hesitance to invest to fix this flaw in name of better UX. This issue has been open since Nov and for good part of that time most of the responses are in line of we know better than you how you should do your job.

@asadighi It's all in your head and your nonsense shows in your comments, stop it.

@muellerkyle :+1: you should create an issue against the bookmark extension you use.

I'm looking forward to this feature

+1!

Daily, I switch between Eclipse, PhpStorm, Notepad++ and VSCode. Guess what, CTRL+W drives me nuts.

I am late to this party, but are the tabs going to be optional? I use to think I missed them but now I don't. Just curious if there will be a way hide them. No hate towards tabs and people wanting to use them, just think I would prefer an toggle to show/hide. That's all keep up the great work. I love vscode.

@jamesmenera yes, it's going to be optional but so does the working files (open editors).

as an aside, would you divulge what program you used to make those mockup pictures?

@ciel, @stevencl wrote that they used PowerPoint for it.

Personally, I love WireframeSketcher to do it but PowerPoint can work too. :)

Just as @jamesmenera mentioned i really miss the tabs and sidebar but i can see that a lot people like the Working Files approach so it should be optional.

@kadza93 both tabs and working files are going to be optional... I wonder how many times I'm going to write it.

It's really easy to do a search and look for the word "optional", it's going to take you less time to find it than actually write a post about it!

@eyalsk I wonder why the flame ! I'm here to express my need and as far as i can see the need of many for tabs, so by supporting what others said and agreeing to it i'm doing something wrong ? By the way thanks for the tip on the search functionality i'm ought to use it more on long threads where i want to express my opinion and if someone already did express similar to mine i will just skip it.

It was only 3 up from your post...

Following this thread, it sounds to me like there are already some decisions made on tabs for a future release (tabs being optional, where the icons will display, key combos, etc.). If I'm not wrong, is there a list of these decisions people can be pointed to?

@jtlowe there's no easy way to make it obvious like pinned comments on GitHub though. People make new comments and it buries the important stuff. GitHub also does comment folding when there are too many comments which makes finding in page harder.

Perhaps the admins can put a "CURRENT STATUS: IN-DEVELOPMENT" banner on the top of the issue page (under the OP's issue-body)?

This should be a proper feature in github --- something like the alt-text here suggests: https://xkcd.com/979/

@kadza93 I didn't flame you... but whatever.

I'm here to express my need and as far as i can see the need of many for tabs, so by supporting what others said and agreeing to it i'm doing something wrong ?

No, you didn't do anything wrong but you didn't write anything useful either, the emoticons/reaction feature exists specifically for this reason.

By the way thanks for the tip on the search functionality i'm ought to use it more on long threads where i want to express my opinion and if someone already did express similar to mine i will just skip it.

Yeah... you're making a lot of sense, I mean expressing an opinion about something that was confirmed! and you didn't even need to search for it because I replied to the same person you gave thumbs up.

Generally, it's common sense to search for a probable common words in a long post.

Really devs should just open a new issue with FAQ and details taken from
the most common points in this thread and close this issue. People
subscribed to this issue are getting dozens of emails every day for the
same "thumbs up" / "thumbs down" comments.
On May 18, 2016 1:51 AM, "Kumar Harsh" [email protected] wrote:

Perhaps the admins can put a "CURRENT STATUS: IN-DEVELOPMENT" banner on
the top of the issue page (under the OP's issue-body)?

This should be a proper feature in github --- something like the alt-text
here suggests: https://xkcd.com/979/

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-219798727

@anyong yeah I completely agree! there's nothing to discuss and once tabs and open editors are live they should create two separate issues for feedback about these features.

@eyalsk we're still experimenting with how to handle updates on community created issues. There are a bunch of ways to do this but they're all kind of bad without a pinned comment feature on GitHub. The integrated terminal issue https://github.com/Microsoft/vscode/issues/143#issuecomment-213581854 has been fine so far with a big update in the middle of the thread, I guess it has to do with less need for discussion so it hasn't been buried.

@Tyriar well, you can reference posts, so can't you just create new posts and make a reference to old ones by closing them? I think that this is how the guys that work on Roslyn do it and then they have a post that summarizes all the features for upcoming releases but nonetheless I agree with you, pinned comments can be extremely useful.

We have been working on implementing the designs for tabs and editor groups in this milestone and will continue to do so in the next milestone

Thanks to everyone who participated in the UX study these last couple of days. We got some great feedback from you that has helped us make some improvements to the experience:

• Redesign the overflow icon
• Provide a setting for choosing whether or not files from quick open are pinned or previewed
• Add a command to turn a previewed file into a pinned file

Sorry, if I've missed that, but how do we enable tabs ? Are they available in the latest insider build, as I have it, but no trace of tabs there. I also still see 'working files' in explorer, while it seems it should be replaced by 'Opened Editors' as stated in #6536.

@lllopo they're not available yet. The stacks/open editors were merged in for v1.3.0 and will be available in Insiders next week when daily builds become available.

+1

+1

👎

Whats going on here, why do you resist giving us an option to use tabs? 😕
So many people like tabs including me, give us the damn option PERIOD!

@aminroosta Seriously... can't you read? are you blind?

Funny thing is you're asking what's going on here... and then go on and assume they actually decline it or in your own words "resist" when in fact they confirmed tabs are coming and working on implementing it!

Some people in this world! unbelievable!

@eyalsk
I spent 25 minutes reading first 20 to 30 comments.
I got tired and left a comment which now seems to be a mistake fro my part.

Sorry about that.

We cannot blame microsoft R&D to try to inovate. Tabs system has cons.

UI design is like all form of design. 90% making what user wait for, 10% making new things, trying to create a new revolutionnary and user friendly system.

all user friendly system seen as must have in new text editor today has been experimented and controversial before.

@aminroosta I'll give you a tip, when you're reading a long post, read the original post and then to get the latest updates spend a min or so on scrolling from the bottom to the top.

That's a good suggestion as this a VERY long feed.

On Sun, Jun 5, 2016 at 10:42 AM Eyal Solnik [email protected]
wrote:

@aminroosta https://github.com/aminroosta I'll give you a tip, when
you're reading a long post, read the original post and then to get the
latest updates spend a min or so on scrolling from the bottom to the top.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment-223826495,
or mute the thread
https://github.com/notifications/unsubscribe/AAInRHy6TDR-opr-8ZKmW-lRUgZDOP21ks5qIwqIgaJpZM4GljE8
.

Personally I like the Ctrl+Tab approach. From my personal experience, tabs can get messy quickly if you have 10+ of them open at the same time. I'd say remove the "working files" or at least leave it as an option. I don't use it and it adds confusion for me. I'll use Ctrl+Tab from here on thanks!

@adred Both Working files (now called Open editors) and Tabs are going to be optional as far as I can tell.

@bpasero

Can you _please_ lock this thread and open a new one with the important bits of this one copied into it? There are still comments coming in daily from people who can't read it all (should tell you it's too long), and asking the same question over and over again, and once the release of tabs hits the public builds we're going to see even more spam in this thread.

I want to stay up-to-date on tab-related happenings, and this thread is currently the place to do that, but it's super annoying to get spammy emails multiple times a day for the same comments over and over again.

Apologies for tone & thanks.

There are so many +1s that it is a bit much.

On Mon, Jun 6, 2016 at 2:16 AM -0700, "anyong" [email protected] wrote:

@bpasero

Can you _please_ lock this thread and open a new one with the important bits of this one copied into it? There are still comments coming in daily from people who can't read it all (should tell you it's too long), and asking the same question over and over again, and once the release of tabs hits the public builds we're going to see even more spam in this thread.

I want to stay up-to-date on tab-related happenings, and this thread is currently the place to do that, but it's super annoying to get spammy emails multiple times a day for the same comments over and over again.

Apologies for tone & thanks.

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/Microsoft/vscode/issues/224#issuecomment-223906131

Just a comment on the update text @ https://code.visualstudio.com/updates#_workbench

The text was unclear to me and I actually thought that the updated stacks were already here (and that tabs would come later). After updating I didn't see the updated stacks and had to re-read the text a few times.

To me it says that Tabs will take more iterations (so no tabs in _this_ update), but that in May you made great progress on how to manage stacks of editors (so despite there being no tabs, updated stacks _are_ in this update?) and that there is more work to be done for the June release branch (to improve stacks even further?).

So to anyone who may have been confused like I was.. looks like updated stacks are not actually in this update. I guess it's just a preview of both tabs and stacks to come.

I agree with @RyanEwen. I really appriciate the open development and amount of communication, but these announcements being part of the official "Release Notes" is really confusing.

Maybe this can be split up into actual release notes, and 'what we're working on right now' or something.

Linking this issue in the Roadmap has not been a good idea because if you read it from the first time you will not get a clear idea of the current status ( more than the Milestone). There's still job to be done but the current state is okayish :+1:

Yeah, they should summarize issues and then have links to these summaries so people would know the current plan after it was discussed.

Linking to discussions is bad because they tend to be lengthy and people can't get the idea without reading almost everything but dunno maybe it's not possible for them to do it otherwise.

When I started reading the release notes for 1.2, the first thing I looked for was _the Tab Feature_. I appreciate that they put the current status there. But I also got confused. At first I thought it landed, than I realized it didn't, but a lot of progress was made. In that case it really feels like that item should be at the bottom of the release notes with a link to the discussion or a milestone (they both prove the progress on the feature) along with a small note saying something like _"Check out the progress towards Tabs implementation"_.

Regardless of this minor thing. Great job on the release. VS Code is a great product with amazing development cycle.

VSCode just updated to 1.3.0-insider. Recent files seems to be gone. Is there a way to do that now?

Thanks for the feedback on the release notes and sorry for the confusion. I've made modifications to the doc to make it clear the work is not in Stable, but that you can preview the tab work in the Insiders Release.

Having a section towards the end where we talk about work accomplished but not in the stable build is a good idea and we'll do that next month if we have more work that fits into that bucket.

@JoshClose please open a new issue for this as I will be locking this issue shortly in favor of individual issues instead of this single thread. thx.

First, let me thank everyone one more time for your thoughts, likes, and dislikes about tabs. The feedback we have seen in this thread (both positive and negative) really shows how passionate people are about the future of VS Code.

I think everyone can agree that we've exhausted the utility of this issue and as a result I am going to lock the conversation. We will leave this issue open until we ship with an option for tabs/no tabs, which we plan to do by the end of the June 2016 iteration.

While the VS Code team _may_ post updates in this issue, you should expect that we will create new issues for additional tab designs or discussions. We will mark issues with the tabs label to make it easier to query. You too can open new tab specific issues and we look forward to your feedback on the specific issues, as together we build the best experiences possible.

Thanks again, now go and install the Insiders Release!

https://github.com/Microsoft/vscode/issues/6605 documents all the added or changed command identifiers to use with keybindings. Because the stacks model is such a large change to the UI of VS Code, we decided to revisit all commands that relate to editors or groups.

We are happy to announce that you can now enable tabs in our nightly insider builds (http://code.visualstudio.com/Download#insiders). The related setting is workbench.editor.showTabs. Please refer to our release notes for more details on the concept of editor stacks, preview editors and tabs.

There is still some work planned in this area until the end of the month (and probably beyond) so we are happy to gather feedback from insiders. Feel free to open issues as you find them while using tabs.

Thanks!

As @bpasero has mentioned you can now enable tabs in our nightly insider builds.

If you have tried this and can spare 30 minutes to share your feedback, please sign up for a chat here: https://calendly.com/stevencl/vs-code-tabs/

Unfortunately I can only offer time slots during the day my time (I am in Edinburgh, Scotland) Monday and Tuesday next week.

tl;dr; enable tabs in VS Code insiders build with workbench.editor.showTabs: true

We are closing for the June milestone during this week with our usual endgame testing. Tabs are on the test plan (https://github.com/Microsoft/vscode/issues/7854) and will get some coverage during the week. We still expect to do fixing on tabs for June and possibly refinements based on feedback post June. The majority of the work is done though, so I will close this issue.

From the description of this work item, @TurkeyMan asks for having tabs and a way to move a tab out of the workbench to open inside a new window. I have extracted the latter into https://github.com/Microsoft/vscode/issues/8171 since it is not related to the tabs work we did.

Please continue to file issues on tabs as you see them while trying them out. Thanks for helping in testing the insiders build!