New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proper tabs for open files #224

Closed
TurkeyMan opened this Issue Nov 19, 2015 · 411 comments

Comments

Projects
None yet
@TurkeyMan

TurkeyMan commented Nov 19, 2015

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

@inakianduaga

This comment has been minimized.

inakianduaga commented Nov 20, 2015

+1

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

@bpasero

This comment has been minimized.

Member

bpasero commented Nov 20, 2015

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

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

@vasumahesh1

This comment has been minimized.

vasumahesh1 commented Nov 29, 2015

+1

@egamma egamma modified the milestone: Backlog Dec 10, 2015

@snehilmodani

This comment has been minimized.

snehilmodani commented Dec 18, 2015

👍

@bpasero bpasero added the workbench label Dec 18, 2015

@Xety

This comment has been minimized.

Xety commented Dec 21, 2015

👍

@Nicte

This comment has been minimized.

Nicte commented Dec 21, 2015

+1

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

@bpasero

This comment has been minimized.

Member

bpasero commented Dec 21, 2015

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

@snehilmodani

This comment has been minimized.

snehilmodani commented Dec 21, 2015

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

@bpasero

This comment has been minimized.

Member

bpasero commented Dec 21, 2015

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

@snehilmodani

This comment has been minimized.

snehilmodani commented Dec 21, 2015

That would be great!

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

@bpasero

This comment has been minimized.

Member

bpasero commented Dec 21, 2015

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

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

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

@inakianduaga

This comment has been minimized.

inakianduaga commented Dec 21, 2015

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

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

@bpasero

This comment has been minimized.

Member

bpasero commented Dec 21, 2015

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

@snehilmodani

This comment has been minimized.

snehilmodani commented Dec 21, 2015

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

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

@bpasero

This comment has been minimized.

Member

bpasero commented Dec 21, 2015

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

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

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

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

@bpasero

This comment has been minimized.

Member

bpasero commented Dec 21, 2015

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

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

@snehilmodani

This comment has been minimized.

snehilmodani commented Dec 21, 2015

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

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

@stevencl

This comment has been minimized.

Member

stevencl commented Dec 21, 2015

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.

@stevencl stevencl referenced this issue Dec 21, 2015

Closed

Improve workspace management #1133

2 of 4 tasks complete
@snehilmodani

This comment has been minimized.

snehilmodani commented Dec 22, 2015

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

Sign me up!

@TurkeyMan

This comment has been minimized.

TurkeyMan commented Dec 23, 2015

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

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

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

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

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

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

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

@Xety

This comment has been minimized.

Xety commented Dec 23, 2015

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

👍

@bpasero

This comment has been minimized.

Member

bpasero commented Dec 23, 2015

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

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

@Nicte

This comment has been minimized.

Nicte commented Dec 23, 2015

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

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

@kfranqueiro

This comment has been minimized.

kfranqueiro commented Dec 23, 2015

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

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

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

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

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

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

@bpasero

This comment has been minimized.

Member

bpasero commented Dec 23, 2015

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.

@Tyriar

This comment has been minimized.

Member

Tyriar commented Jun 1, 2016

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

@jan-zajic

This comment has been minimized.

jan-zajic commented Jun 2, 2016

+1

1 similar comment
@krisquigley

This comment has been minimized.

krisquigley commented Jun 2, 2016

+1

@nmoore2

This comment has been minimized.

nmoore2 commented Jun 3, 2016

👎

@aminroosta

This comment has been minimized.

aminroosta commented Jun 5, 2016

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!

@eyalsk

This comment has been minimized.

eyalsk commented Jun 5, 2016

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

@aminroosta

This comment has been minimized.

aminroosta commented Jun 5, 2016

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

@Guema

This comment has been minimized.

Guema commented Jun 5, 2016

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.

@eyalsk

This comment has been minimized.

eyalsk commented Jun 5, 2016

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

@glennblock

This comment has been minimized.

glennblock commented Jun 5, 2016

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

On Sun, Jun 5, 2016 at 10:42 AM Eyal Solnik notifications@github.com
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
#224 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAInRHy6TDR-opr-8ZKmW-lRUgZDOP21ks5qIwqIgaJpZM4GljE8
.

@adred

This comment has been minimized.

adred commented Jun 6, 2016

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!

@eyalsk

This comment has been minimized.

eyalsk commented Jun 6, 2016

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

@anyong

This comment has been minimized.

anyong commented Jun 6, 2016

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

@Mikewl

This comment has been minimized.

Mikewl commented Jun 6, 2016

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

On Mon, Jun 6, 2016 at 2:16 AM -0700, "anyong" notifications@github.com 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:
#224 (comment)

@egamma egamma referenced this issue Jun 6, 2016

Closed

June Iteration Plan #7253

116 of 120 tasks complete
@RyanEwen

This comment has been minimized.

RyanEwen commented Jun 6, 2016

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.

@remcoros

This comment has been minimized.

remcoros commented Jun 7, 2016

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.

@javmonisu

This comment has been minimized.

javmonisu commented Jun 7, 2016

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 👍

@eyalsk

This comment has been minimized.

eyalsk commented Jun 7, 2016

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.

@andradei

This comment has been minimized.

andradei commented Jun 7, 2016

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.

@JoshClose

This comment has been minimized.

JoshClose commented Jun 7, 2016

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

@chrisdias

This comment has been minimized.

Member

chrisdias commented Jun 7, 2016

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.

@chrisdias

This comment has been minimized.

Member

chrisdias commented Jun 7, 2016

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

@chrisdias

This comment has been minimized.

Member

chrisdias commented Jun 7, 2016

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!

@Microsoft Microsoft locked and limited conversation to collaborators Jun 7, 2016

@bpasero

This comment has been minimized.

Member

bpasero commented Jun 9, 2016

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

@bpasero

This comment has been minimized.

Member

bpasero commented Jun 19, 2016

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.

image

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!

@stevencl

This comment has been minimized.

Member

stevencl commented Jun 21, 2016

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.

@bpasero

This comment has been minimized.

Member

bpasero commented Jun 27, 2016

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 (#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 #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!

@bpasero bpasero closed this Jun 27, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.