microsoft / vscode

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

Pinned tabs: show them in a secondary tab row above others #98160

Closed bpasero closed 1 year ago

bpasero commented 4 years ago

Refs: https://github.com/microsoft/vscode/issues/12622

Pinned tabs by default will show to the left of other tabs. An alternative presentation is to do what Visual Studio does and have a secondary tab row above the others:

image

vs what we do today:

pin-tabs

yannlairdc commented 4 years ago

Here's why I would like to get the pinned tab VS style:

I use pinned tab has my main work focus. I usually have between 2 to 5 tabs pinned and all the tab noise of opening / looking / searching / inspecting is kept out of it. So when I find what I'm looking for, I can instantly go back to the focused tabs and they are clearly delimited on their own row.

It's a huge productivity booster for me to be able to organise tab like that.

bpasero commented 4 years ago

@yannlairdc pinned tabs in VSCode are always the first tabs of the row and never scroll out of view, does that still require a secondary row then?

yannlairdc commented 4 years ago

@bpasero It's all about visibility and speed of access to what you're looking for. I will say that having this improvement without the other feature to display the full name of the pinned files reduces the value of that one alone.

When I'm looking for something or iterating through references in the code, I can go back to where I was at the glance of an eye. I know it's going to be on the first row, I know it's not going to move whatever I do and I know which tab I need to go back to with the name displayed.

It allows me in my head to have the first row as my area of focus, while everything in the second row is just "noise" that I disregard.

Having everything pinned in the first rows without the name display is a nice addition, but not quite there for me. The reason it works well with chrome tabs is because the content of those pinned tab never changes and it's easy to recognise the icon of the website in case of doubt. Witt VS Code, the files pinned changes regularly and most of the time they are of the same type.

Having 7 pinned tabs with a C# icon on them would still force me to iterate on each tab until I find back the tab I'm interested in, while pushing to the right all the others opened tab.

bpasero commented 4 years ago

@yannlairdc yeah understood, assume you have a setting to show the name of a tab even when pinned. Would that be sufficient to not add another row of tabs?

yannlairdc commented 4 years ago

@bpasero That would be another good step in the right direction for sure, but it wouldn't solve all the problems. If you have 6 or 7 pinned tabs with their full names displayed, their's a high chance that it will occupy most of the screen and left out the non pinned tabs.

By the way, I just realised something by looking at both VS and Code and the tabs in Code are much bigger than in VS, which makes the above problems more critical (see below).

image

If I have 6 pinned tabs, it would occupy most of the space opened on my 27" screen. Is there any option to be able to reduce the size? Or put them on several rows maybe?

bpasero commented 4 years ago

@yannlairdc you might want to check out "workbench.editor.tabSizing": "shrink" setting which will ensure tabs start to shrink to a minimum of 80px when space is limited.

To be clear: I would only suggest a solution that makes pinned tabs shrink too so that you can have many pinned tabs side by side without starting to scroll. E.g. one idea is to make every pinned tab shrink as if "workbench.editor.tabSizing": "shrink" as configured.

yannlairdc commented 4 years ago

@bpasero If we can get the pinned tab on a separate row, this problem almost solves itself.

bpasero commented 4 years ago

I am trying to find a design alternative that does not require a second row of tabs which I personally find very heavy visually.

yannlairdc commented 4 years ago

I understand that not everyone would like a second row, but that's what I'm looking for (and that's the title of this enhancement request ^^).

I'm not asking for it to be the default behavior or to replace current implementation, I would just like the ability to configure it this way for me and other likeminded people (lot of them requested that specific behavior to be implemented on the original pinned tabs topic).

GreenAirplane commented 4 years ago

I 100% agree with @yannlairdc. I have exactly the same use case. In most cases, I have 3-5 pinned tabs and a bunch of tabs on the 2nd row in VS. The ability to have full names for the pinned tabs is crucial as well because e.g. if I'm working on some backend feature then all or most of my files will be *.cs.

One more thing, with the ability to pin tabs, it would be nice to have the option to "Close all but pinned" tabs.

bpasero commented 4 years ago

The ability to have full names for the pinned tabs is crucial

Which https://github.com/microsoft/vscode/issues/98161 would try to cover too.

One more thing, with the ability to pin tabs, it would be nice to have the option to "Close all but pinned" tabs.

That should already work today, pinned tabs should stay open for mass closing commands.

ChuckkNorris commented 4 years ago

Not intending to "beat the drums", but I definitely believe that having pinned tabs on a separate row will be more beneficial than "shrunk" tabs on the same row as the rest of the tabs.

From a functional perspective, we want to be able to:

I understand the desire to come up with a less "heavy" solution, but I'm not quite sure what that would look like without sacrificing some functionality.

jeffpedneau commented 4 years ago

Not sure what "heavy" is, but if I want to pin a tab above the others, I'm opting in on it having a bigger visual footprint (if that's what you meant). Angular file names tend to be enormously long, and I never get more than about 4 across, and I hate the scrolling -- would much rather than wrap. I'm always hunting, so using more rows is fine with me.

I'd also have more room if I could drag some of them out to separate windows....or the Explorer off.

dean1010 commented 4 years ago

How about having all pinned tabs in one tab with a drop down on hover (or click)?

GorvGoyl commented 4 years ago

Just so you know there's also a SO question for multirow tabs (50+ upvotes) so that does kind of provide validation for demand. https://stackoverflow.com/questions/42462777/multirow-tabs-for-vscode. There's also mention of custom CSS hack to get multirow tabs meanwhile.

jeffpedneau commented 4 years ago

dean1010's idea isn't bad -- anything that conserves horizontal space and stacks potentially wide names on top of each other without truncation is better...

marko-hologram commented 4 years ago

If I had to pick, I would probably choose this secondary tab row option since you can easily see all open tabs and their names at a glance. Having them just showing an icon it's hard to actually see what you have pinned if you have multiple files pinned that have the same extension.

I'm just wondering what should happen if you pin a bunch of tabs and they span outside the editor view, should they scroll as current tabs in VS Code should they wrap? As is the case with Visual Studio for example. Also, should there be a keyboard shortcut to toggle between pinned tabs? Like CTRL + PageUp/PageDown that's available now for open editors.

Ideally, it would be great if you could implement secondary tab row option AND this one (https://github.com/microsoft/vscode/issues/98161) and then offer the user to choose first one OR the second one. I'm just not sure how much resources would that require in order to be implemented. VS Code always seems to have a bunch of options for everything, so it would be in VS Code "spirit" to offer multiple configurations for this issue, but I understand it might not be viable to do so.

How about having all pinned tabs in one tab with a drop down on hover (or click)?

* [ Pinned ]

  * [ file1 ]
  * [ file2 ]
  * [ etc   ]

Hmm this looks like a decent compromise to me. It doesn't add multiple rows of tabs on top (as it looks that is not preferred by the devs) and it can still display file names when you open it. I would also love a keyboard shortcut that would allow you to open/close it so you can quickly inspect what you have pinned without having to move your hands from the keyboard.

Only problem I see with this approach is if you pin 10-15 files and the list becomes tall, so probably limiting the height and introducing scroll would resolve this, but then you wouldn't be able to see all pinned tabs at once.

DavidZidar commented 4 years ago

Seeing how similar the pinned tabs are to pinned browser tabs I would like to add that I think they are completely different animals.

Pinned browser tabs are often from different sites with visually distinct icons and they are often open long term, but they stay mostly in the background.

Pinned code tabs are often of the same file type so the icons are all the same, they are open short term, but are the most important tabs open at the moment and needs to be easily available.

Having pinned code tabs on a separate row with full titles like in Visual Studio is very helpful.

moonflame commented 4 years ago

Current pinned tab style may also cause misunderstanding frequently, like this(I pinned a JS file): confused icon

Besides this reason, I prefer the 2-row style.

I also agree with @yannlairdc that the size of tabs in VS Code is too large, either in width or height. Hope there are options to modify the tab size more flexibly.

theopenroad commented 4 years ago

Another vote for pinned tabs having their own row, possibly with a different background color too. When I'm working in a large project with many files of the same type, I end up having anywhere from 4-8 files that I need quick access to. I need to be able to see the file names, not just the icon.

Having 2 rows would be extremely helpful to my workflow.

The visual studio example looks great.

chibibiscuit commented 4 years ago

I would love for Pinned Tabs to have their own row, but I would also like to see them get some UI treatment in the File Explorer pane. Giving them either their own group or section, or a pinned indicator could alleviate the frustration, at least in a workaround fashion.

lendup-erikschlegel commented 4 years ago

Having pinned tabs that exist on a separate row is a fantastic productivity booster, but the brownie points version of this is to support a dynamic number of rows. IMO pinning a tab should not automatically create a separate row. But when a user drags a tab (pinned or not) up or down beyond some threshold the IDE would spawn a new row onto which the user can drop said pin. This would then allow for multiple rows of pins. Perhaps I want a row for configs, another for base classes, another for utility classes, etc. I've looked for this feature in every IDE ever, but have never found it.

vicmarcal commented 4 years ago

Not sure about the secondary row, it steals some space and doesn't attack the source of the issue: as soon as you start working with files from one or other project, you end with tons of files opened.

Now that you can pin a Tab, probably is time to have a solution which grows from Dumb to Smarter:

Dumb Tab Row

The Dumb Tab row just shows the Tabs related to the active repo/folder in Workspace. If you change to a file from a different repo/folder, files unrelated to the new folder are hidden but the pinned ones.

Ie: if I am working in the Frontend Repo, with F1, F2, F3 files/tabs opened and I am going to open the file B1 from my Backend Repo I can pin the, ie, F1 tab, before clicking in the B1 file. As soon as I open/click the B1 file the F2,F3 tabs are hidden but not the F1 one since it was pinned.

I can keep working in my Backend project opening files, B2,B3,B4, B5. But as soon as I click in the F1 tab/file, the F2, F3 files which were hidden are revealed and B1,B2,B3,B4,B5 are now hidden.

Tabs are not closed but hidden, so it is fast to swap from project F to B while keeping the Tab bar tidy.

Also it will help us with two scenarios I usually find:

1 - Workspace with unrelated projects.

2 - Workspace with related project. Typical Front-Back. I am working in a GET controller in the B1 file, implementing a middleware B2, a router B3, etc... Now I decide to swap to the frontend file F1 which is calling the controller in B1. I would be pinning B1 tab, to not lose it from view when opening F1. As soon as I start editing F1, the rest of B files, but B1 which is pinned, are hidden, making room and reducing noise from my frontend work (as I will start open F2, F3,F4 files...). However if I suddenly detect a problem in my B code not sitting at B1, as soon as I click in the B1 file, B2, B3 and the B files I was using are shown..and F are hidden, helping me to swap fast from Front to Back.

This Dumb behavior would help a lot because it kills tons of unneeded files/leftovers but at the same time helps to swap easily from project to project.

I usually work with 3 projects at the same time, Front Web, Front Mobile, Backend...so the mess is 3x and Dumb Tab Row will help a lot.

Smarter Tab Row

TLTR: Just show related Files to the Project, unless they are pinned or recently touched/saved. It helps when swapping from project to project in the same Workspace by hidding unneeded files.

lendup-erikschlegel commented 4 years ago

I usually work with 3 projects at the same time, Front Web, Front Mobile, Backend...so the mess is 3x and Dumb Tab Row will help a lot.

A humble suggestion, @vicmarcal, which, it seems, could side-step your raised issues while also offering other benefits to your workflow: what if you opened three instances of VSCode (one for each project). This, presumably, would also help you with things like file searches, debugging, commits, console commands, etc as each IDE instance is constrained to the particular project's workspace. After a reboot or closing your VSCode instances, you can easily get back to work by popping up a console, cd'ing to a project's folder, and running 'code .'. Using this setup, you'll find that each project maintains its own tab set, previously opened files, etc.

I've recently adopted this strategy and have found it works a lot better for me than one instance with multiple open projects.

sucom commented 4 years ago

This is a great feature. Thanks for it. I would prefer to have an option to show the file name or not. If I pin multiple javascript or same type of files. It shows only icons but it's difficult to remember the file names.

Thanks

RieksJ commented 4 years ago

Personally, I like the idea of dropdown boxes of @dean1010. Given the big support for having a secondary row makes me wonder if it would be feasible to have both, and leave it up to the user to configure which (if any) (s)he wants to use.

RieksJ commented 4 years ago

Working predominantly in settings that requires integration between files from various sources where each source addresses different topics, I would love to see multiple (named) dropdown boxes, that allow me to tack files from one source under the corresponding dropdown box. It's a bit like what workona does in browsers.

vicmarcal commented 4 years ago

I usually work with 3 projects at the same time, Front Web, Front Mobile, Backend...so the mess is 3x and Dumb Tab Row will help a lot.

A humble suggestion, @vicmarcal, which, it seems, could side-step your raised issues while also offering other benefits to your workflow: what if you opened three instances of VSCode (one for each project). This, presumably, would also help you with things like file searches, debugging, commits, console commands, etc as each IDE instance is constrained to the particular project's workspace. After a reboot or closing your VSCode instances, you can easily get back to work by popping up a console, cd'ing to a project's folder, and running 'code .'. Using this setup, you'll find that each project maintains its own tab set, previously opened files, etc.

I've recently adopted this strategy and have found it works a lot better for me than one instance with multiple open projects.

Thanks for the suggestion, however, for me, that kind of "opening two Visual Codes" seems like an UIX hack after all. Since Visual Studio is not providing a good experience when having two projects opened, let's open two different windows.

I know a lot of mates working that way, so basically it means there is an UIX issue to be fixed, and Pinned tabs seems to be an approach to try to fix that. My suggestion tries to enhance a little bit more the Tab row behavior to make it a little bit better. I highly doubt that Pinned Tabs just on its own will fix the mess of tabs I already have.

dashesy commented 4 years ago

Would be great to keep the pinned editors in the "explorer" section, and not have anything that occupies the row (not even a second row) I work with projects with hundreds of files and usually I only deal with a handful. Would be great to use the "explorer" like a bookmark to quickly navigate between these files.

lendup-erikschlegel commented 4 years ago

I work with projects with hundreds of files and usually I only deal with a handful. Would be great to use the "explorer" like a bookmark to quickly navigate between these files.

Hey there, @dashesy -- I wonder if perhaps "pinning" isn't the droid you're looking for. If I'm reading you correctly, it seems maybe Zuo's "favorites" extension might be a better match for your workflow?

eliashdezr commented 4 years ago

I'm on the side of having a separate row for pinned tabs.

The points made by @yannlairdc are spot on. If you have been using Visual Studio IDE, you would know about this productivity boost. I hope this can be shipped!

ChuckkNorris commented 4 years ago

I am trying to find a design alternative that does not require a second row of tabs which I personally find very heavy visually.

That's fair, but if you have a large monitor and high resolution then a second row barely takes up any screen real estate and can do wonders for productivity since you don't have to discern between pinned/unpinned tabs.

Perhaps a configurable "Pin Tabs to Separate Row" option would make everyone happy. If it's not set then pinned tabs are just pinned to the far left of the single row as expected.

Does a second row appear to be too heavy in this situation? image

JordanHoffman commented 4 years ago

If the goal is to maximize space-saving, then I think the very top frame of the window could be used as the second row. There's a bunch of dead space, and the main thing in the center is "file name - project name - Visual Studio Code". I don't know where this info could be moved to, but if you could move it, then that very top frame becomes a second row in itself.

Edit: I just noticed the blue bar at the very bottom which also has a ton of dead space. Maybe that blue bar could be moved to the top, stacked under the main bar (this isn't adding any additional space, just rearranging). Then you could put all the title information in the middle of the blue bar and allow for the new row in the very top frame.

yulei900609 commented 4 years ago

i like that, please do it right now.

mmhoang commented 4 years ago

My preference is 1 row with the pinned tabs all the way on the left, but 2 rows is doable on my monitor. Either way, really looking forward to pinned tabs that have the file name/path on them!

lendup-erikschlegel commented 4 years ago

Given our wide variety of preferences wrt VSCode's default handling of rows/pins, there really is no silver bullet--we could debate for or against one, two, or n rows, but this won't get us anywhere. Really, the UI ought to be moldable to suit whatever need the user wants for a particular project. People who want only one row can have it. People that want more can have that, too. I'd like to point back to my above suggestion (on Jun 11) which takes this into account.

Having pinned tabs that exist on a separate row is a fantastic productivity booster, but the brownie points version of this is to support a dynamic number of rows. IMO pinning a tab should not automatically create a separate row. But when a user drags a tab (pinned or not) up or down beyond some threshold the IDE would spawn a new row onto which the user can drop said pin. This would then allow for multiple rows of pins. Perhaps I want a row for configs, another for base classes, another for utility classes, etc. I've looked for this feature in every IDE ever, but have never found it.

JordanHoffman commented 4 years ago

This issue feels like the Lord of the Rings trees who want to talk about something really basic for 1000 years before making a decision. Just add an OPTION for there to be pinned tabs like how it is in regular Visual Studio and be done with it. The fact that it's been stuck in limbo for this long makes me become suspicious if this is truly about difficulty/perfection of implementation or if it's some other secret reason. I agree with others. If nothing else, just make this an OPTION!!! Not mandatory, but an option that people can choose to enable or not so that no one can complain. You already have proof it works in regular Visual Studio, so just add it.

yannlairdc commented 4 years ago

Not having those simple options for tab control is pushing me out of using VSCode now. I'm looking into Rider as a replacement for Visual Studio, because at least I can get some level of similarity with VS just for that part (and the fact that it embed resharper as well.) It appears evident that VSCode developers, with their answers to both topics, are not willing to change their vision and make modifications to allow more flexibility and more use cases. They want it browser-tab like and that's it.

Unsubscribing from this as I'm pretty sure nothing will be done in the next 6months to a year at the very least.

mihaibrana commented 4 years ago

Aside from all its other advantages, allowing us to have a second tab row has one major advantage: it would make it easier for developers to come up with extensions to handle a lot more scenarios for tab sorting (such as per project, per status (pinned, dirty)).

mihaibrana commented 4 years ago

Not sure how drag & drop will be supported with two tab rows. But it could make the pinned icon redundant. If one wants to unpin a tab one can drag & drop it to the desired location (this would also allow one to choose the position of the tab among others).

It's indeed a fidgety problem to solve, although I don't get some of the negativity surrounding this. It's wonderful we got the feature, now it's simply a matter of patiently tweaking it. The very fact we have somebody from the team discussing this with us (not on OUR expense) should make everybody do their utmost to participate rather than call it quits.

eliashdezr commented 4 years ago

@bpasero any update on this? General consensus has been very clear about enabling a second row for pinned tabs as an option.

Uglyfatdude commented 3 years ago

@bpasero any update on this? General consensus has been very clear about enabling a second row for pinned tabs as an option.

Anything?

kenpalmer commented 3 years ago

I just requested this same feature, to "Show pinned tabs in a second row" at this thread. https://github.com/microsoft/vscode/issues/110477

My request was rapidly closed as a duplicate. Please give us the ability to add a second row, or to create multiple rows in the code editor.

The latest release, October 2020 (1.51.1) offered a "Workbench" enhancement to make pinned tabs more prominent. A person or team at Microsoft just worked on extending the tabs. Please ask them to give us multiple rows in the code editor.

Here is an example from Visual Studio 2019. image

And how that feature is toggled, via Tools > Options > Environment > Tabs and Windows. image

hersman commented 3 years ago

I'm with everyone else. Having come from C# to JavaScript, the one feature I've missed about Visual Studio compared to VS Code is the second row of pinned tabs. I really don't get why this hasn't just been added as a feature.

kenpalmer commented 3 years ago

I agree, @hersman. My understanding is that this is on their list of items. Apparently we need to upvote the original post from May 19 to increase its priority.

remy90 commented 3 years ago

I'd also like to add the 1018 likes from #12622 making it the fourth most liked feature amongst open issues

antonioacg commented 3 years ago

any update on this?

jeremypcleung commented 3 years ago

Can't believe this feature has been requested since 2016 and outright ignored, seems like such a basic requirement. With my current setup I can only see around 6 files in the tab bar - having more than 10-15 files open means that I have to scroll annoyingly through the top bar to find a file. The pinning doesn't start a new row or even lock the position of the tab or anything so pinning files right now doesn't make it any more organized than it already is. I want to pin tabs to have immediate access to it while browsing through numerous files exploring the codebase. I need VS Code for typescript since VS 2019 goes crazy with the syntax highlighting but this feature would be a real productivity/organization booster.

bekidd commented 3 years ago

Try to use open multiple file and find code you will know why we request a second row not this design. Second row can help to find a new file and when it used often will be category in pinned. Pinned file can help us open them quickly. If vscode has this function, I don't need to open vscode and vs2019 simultaneously when I read code. Personnally I would say your design is ridiculous because it doesn't help create a clear "pin" category but like a folder. Openning folder and find files which we would like open frequently is so ridiculous.

virok commented 3 years ago

image This feature should be implemented, how do I open the file on the left ? Really it should just work like Visual Studio, or at least have an option to choose what do you prefer.