search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
162.19k stars 28.55k forks source link

Proper tabs for open files #224

Closed TurkeyMan closed 8 years ago

TurkeyMan commented 8 years ago

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

nvivo commented 8 years ago

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.

WhatsThatItsPat commented 8 years ago

-1

A few notes for why I'm against tabs:

riclf commented 8 years ago

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.

kfranqueiro commented 8 years ago

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.

jayrosen1576 commented 8 years ago

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!

felixfbecker commented 8 years ago

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.

felixfbecker commented 8 years ago

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.

jayrosen1576 commented 8 years ago

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.

felixfbecker commented 8 years ago

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

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.

jayrosen1576 commented 8 years ago

Here's the proposal for how it should look:

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

felixfbecker commented 8 years ago

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

jayrosen1576 commented 8 years ago
ianwesterfield commented 8 years ago

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

kfranqueiro commented 8 years ago

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

jayrosen1576 commented 8 years ago

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

nvivo commented 8 years ago

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.

JonCognioDigital commented 8 years ago

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

jayrosen1576 commented 8 years ago

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

riclf commented 8 years ago

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

JonCognioDigital commented 8 years ago

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.

msg7086 commented 8 years ago

Browser extensions? Activ... NVM.

ghost commented 8 years ago

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.

nvivo commented 8 years ago

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

rogierlommers commented 8 years ago

Ghehehe, hilarious!

Op za 12 mrt. 2016 om 11:57 schreef Natan Vivo notifications@github.com

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

ghost commented 8 years ago

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

TurkeyMan commented 8 years ago

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

ghost commented 8 years ago

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

ianwesterfield commented 8 years ago

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.

nvivo commented 8 years ago

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

ghost commented 8 years ago

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

TurkeyMan commented 8 years ago

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

jayrosen1576 commented 8 years ago

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.

nvivo commented 8 years ago

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:

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.

jayrosen1576 commented 8 years ago

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.

ianwesterfield commented 8 years ago

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.

JonCognioDigital commented 8 years ago

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

jayrosen1576 commented 8 years ago

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.

ianwesterfield commented 8 years ago

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

ianwesterfield commented 8 years ago

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

JonCognioDigital commented 8 years ago

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

ianwesterfield commented 8 years ago

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

bpasero commented 8 years ago

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.

ianwesterfield commented 8 years ago

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

iam3yal commented 8 years ago

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

ianwesterfield commented 8 years ago

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

bpasero commented 8 years ago

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.

iam3yal commented 8 years ago

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

jayrosen1576 commented 8 years ago

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

glennblock commented 8 years ago

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!

castrojunin commented 8 years ago

+1

Extremely necessary.