Allow to shrink tabs instead of keeping a minimum width

[stefcameron]

• VSCode Version: 1.7.1
• OS Version: OSX 10.11.6, Windows 10

Steps to Reproduce:

1. Open many files in the same editor until there are more tabs (per file) than can fit in the editor's tabbar real estate.

Once filled, the tabbar enables horizontal scrolling to see hidden tabs to the left/right. That's really not user friendly... and it's especially frustrating when splitting the main window into 3 editors, and then opening multiple files in each editor.

I think having a workbench setting to choose between this scroll-based tabbar behavior and a new behavior where the tabs would "compress" (i.e. begin to reduce the horizontal width of all tabs in the related editor such that less of the file's name is visible in each tab until only the close "x" button is visible per tab) would be a welcome addition to tab management.

[stefcameron]

FYI, I'm not sure if this feature request is a duplicate of issue #7987. A comment by @rocksthehouse is the same thing, but seems like an issue in another issue...

[bgse]

@stefcameron Excuse me for giving the advocatus diaboli here, but what would shrinking the tabs really accomplish here?

At best, we'd be able to fit a couple more tabs in there before we need a scrollbar anyway, and before we needed the scrollbar, we'd have introduced a negative effect on user experience since we'll end up with tabs that have half the information we need (often times the relevant information is at the end of filename) and get harder and harder to read the more tabs we add, or no information at all and just anonymous tabs we can click through one by one (when there is just the X left).

Scrolling on the other hand works very natural and fluid with mouse, trackpad (and possibly touchscreen, have not tried it), even with a huge number of tabs.

Compression to the minimum required space (for the individual tab) would probably make room for one or two extra tabs before overflow starts, but then again having a uniform width makes for good usability and less UI noise.

All imho, not against the idea in general, just trying to get some discussion going.

[stefcameron]

@bgse I appreciate the discussion. :) You do make some good points, however I use a Wacom tablet and horizontal scrolling in those tabs is really annoying with that tool... It's very awkward at best.

I my mind, having to scroll the tabs is a negative effect on my user experience. I'd prefer it the other way (compress, and never scroll). But I fully recognize others would see it the other way around, hence my suggestion to allow this to be configured.

So I'm coming from Sublime, trying to give Code a good try. Sublime does this type of "compression" I'm asking for here and I find it works really well. I rarely end-up in a situation where I have so many tabs open I can't recognize them by the beginning of the file names (or just positionally, from muscle memory). It literally took me all but 1 minute after opening Code for the very first time to run into this horizontal tab scrolling scenario within an editor (which was hard to discover; at first I had no clue where my tabs went) with barely any files open. Note that I work on a 2560x1440 monitor and always split the layout to 3 vertical editors so I can see and work on 3 files at a time, so that makes the editors narrower.

Of course, having so many tabs open in a single editor that they are reduced to just the close (X) button isn't usable, and I tend to close tabs before it gets to that point (talking from a Sublime perspective).

Right now, I'm discovering some keyboard shortcuts in Code that are making things tolerable, but still not as easy as clicking directly on a tab I know I want, or in the extreme case (in Sublime), positioning my cursor over a tab long enough for a tooltip to show me the full file name.

One key difference between Sublime's tabs and Code's tabs is that Sublime attributes equal width to all tabs (to a maximum) within its equivalent of an editor window, whereas Code gives a tab the width necessary to show the entire file name. Depending on the project, Code's editors can therefore very quickly run out of horizontal tab space.

Now suppose this feature request isn't implemented. Other things that could help would be:

• add a setting option to not show the icon theme in the tabs (only in the Explorer)
• add a setting to control the font/size used for tab titles

Both those settings could help reduce the overall width necessary to display a tab and allow more of them to be displayed before the scrolling becomes necessary.

[bpasero]

We made the explicit decision to never shrink tabs smaller than their file name. It is unlikely that we will change this or add an option, but leaving this open for the good discussion in here.

[zakdances]

There really should be an option to fit all tabs in one screen by truncating their names. It's how Sublime Text 3 works.

[thSteve]

+1

[RenaldasK]

I had no idea that I can scroll the tabs with mouse wheel until I came across this ticket! And even now that I now that, I still find myself not using it and instead close some tabs to fit.

In my opinion the usability of editor tabs would be MUCH better if users could choose to shrink and fit all tabs.

[jroboyd]

Please make this a configurable option. Really annoying coming from sublime text not being able to see all the tabs open with a split screen configuration an no side bar.

And from a design point of view, it is a really common design pattern to condense tab widths, look at chrome, internet explorer, edge (combines elements of both).

[CedricReichenbach]

Being able to truncate file names would be especially helpful when working with long-named files. For example, an Angular project following the convention of suffixing filenames with their respective type may contain files like shopping-cart-preview.component.html. Even a handful of those might already overflow on a customary HD screeen. In particular, the .component.html part is not super relevant and I don't need to see it at all times.

[CreepGin]

The tabs will be much more usable when implemented like the auto-width Chrome browser tabs.

[dkniffin]

I just switched to VS Code from Atom, and this is probably the single most annoying "feature" of VsCode. I always have lots of tabs open (as most of us do), and scrolling through them is giant pain for me. Forcing all the tabs to be full-width is very inconsistent with any tab experience I've seen. Chrome, Firefox, Safari, Atom, and Sublime all do some form of tab shrinking.

Even if it doesn't show the whole name of the tab, having an icon and/or just a few characters showing is often enough for me to know which one it is I'm looking for. In the case where it's not enough info, I'm fine clicking (or cmd+shift+[ing since I usually prefer my keyboard) between them to find the one I'm looking for, but I'd like to see all of them.

[jamesgecko]

This frustrates me constantly when using three vertical editor groups, particularly with files that have long names, or when using Git Lens's stash view.

I have vscode full screen, and that's the entirety of an editor group tab area devoted to a single buffer. Obviously Git Lens could use a shorter name for the buffer, but even with a shorter title like, numbers-bulk-edit-modal.html (6f2881^1) <-> (6f288114) I still wouldn't see all four tabs I currently have open in that editor group.

There's plenty of space for the full title of the file in the window title bar (or the status bar, with an extension). A partial name in the tab bar is fine for switching between buffers.

[stefcameron]

@jamesgecko Exactly my point from long ago! Thanks for putting a picture to it. I'll say it again: IMO, the most important parts of the file path are the beginning and the end. A strategy that collapses the middle of the path, such as rootFolder/dir0/.../dirN/filename, with more collapsing as the horizontal space reduces, such as rootFolder/.../filename, down to filename, would go a long way in improving usability.

One exception to the collapsing, of course, might be that the smallest unique path is retained in the tab if there are multiple files open with the same name (even across editor groups, IMO). That could mean something like dir2/.../myfile.js and dir5/.../myfile.js.

[rodriguezmanu]

+1

[kllystvns]

+1

[bpasero]

Would something like this work for people?

Behaviour:

• active tab is always fully visible (this means even if it has a very long file name it would never shrink)
• there is a minimum size of the tabs still at 60px to at least fit the icon (if any) or the first file name character
• the close button is always visible
• tabs shrink even across all and show a "..." once they are shrinked
• the scrollbar still kicks in if needed

PS: we had a bug in the tabs control where on touch devices it was not possible to touch using the finger, we fixed this in 1.18.

[CedricReichenbach]

@bpasero Looks nice! I think that's a pretty good solution, just one detail: The never-shrinking active tab causes tabs to "jump around" when switching, which might cause slight disorientation. Seeing the current file name in full is probably not always crucial either, so maybe make it configurable too?

[jamesgecko]

I've never seen tabs resize like that, so I went looking for UX research about it. Point 10 in this Nielsen Norman Group article is the closest thing I've found:

Multiple rows create jumping UI elements, which destroy spatial memory and thus make it impossible for users to remember which tabs they've already visited.

That's about multiple rows of tabs instead of tabs that resize, but it still seems to echo @CedricReichenbach's concern about disorientation. It also doesn't improve my use case, where I'm often working with many files that have long names.

I don't understand why showing the full name of the active tab on the tab is such a large concern; the default window.title setting shows it on the title bar right over the tab.

[bpasero]

Yeah I get the point about making it hard to keep a memory of which tab is where if the active one is always pushing the others away. I guess we could just say that a tab will never change its size even if being active.

Basically this would go into a direction of Chromes tab model where each tab gets small enough until only the close button is visible, but you would never get a scrollbar and each tab always has the same width. Since I find that a bit odd too, I would have a minimum width for tabs (we could also think about hiding the icon once the space is too little).

[stefcameron]

@bpasero Thank you for the mockup, and the work that has already gone into making it possible! I think this is a great start toward making lots of tabs more usable, except for the point about the active tab always having its full title visible.

I don't see how that would solve the issue @jamesgecko previously raised on this topic. It seems like keeping the full title of the active tab always visible would defeat the whole purpose of shrinking tabs -- which, in my mind, is to eliminate (as much as feasible) the need to scroll the tab bar (very tedious with a Wacom tablet) and the loss of my ability to visually locate a file just by the fact that I've learned where it's located in the tab bar (even if I can't see its name because only the icon is visible) within an editor group.

[owenisred]

@bpasero the mockup you made looks like a great improvement - really can't wait for something like that to be available!

[kevinmartinez]

Solution suggestion looks good. This is really needed. I have gotten disoriented quite a few times wondering where my tabs went.

[DavidBabel]

Yeah seems great ! Adding an option to let icons disapear if there is not enougth size could be a good approach too.

[bpasero]

Another interesting question: Would people expect each tab to have the same width even if that means the label shows with a "..." although there would be enough space?

In other words: Chromes tab behaviour is very deterministic. Each tab always has the same width, no matter how much space the tabs container has.

To compare with VS Code:

Each tab having same width

Each tab fitting their content if space is available

Independent from the behaviour above, in both cases the tabs start to shrink evenly once space becomes little:

[stefcameron]

@bpasero I would expect each tab to fit its content. As the window narrows, the wider tabs should start to shrink before the tab with the shortest title. Once all other longer tabs are now the same width as the tab with the shortest title, all tabs should start to narrow evenly. The ellipsis takes quite a bit of room. I like how Chrome tabs slightly fade the title away at the edge where it's being cut off. IMO, that leaves a bit more width where an extract character or two, depending on character width, might still fit.

[bpasero]

Yeah I like to show the full contents of a tab if possible, so this is how it would work:

I cannot control how much space the "..." takes because the clipping is done by CSS. I would have to do my own custom overflow behaviour otherwise if I wanted to show less. But we can always tweak that in the future.

[jamesgecko]

Looks good!

Question: if you have two editor groups of equal size, they do not have the same amount of space in the tab bar visible; the diff/split/... buttons appear at the right side on the active tab bar. How will this interact with that? Do all the tabs resize when the active editor group changes? Will each inactive editor group tab bar reserve an empty place for those buttons?

[bpasero]

@jamesgecko the behaviour of the editor actions tool bar is not changing in any way. Actions appear and hide very dynamically as before and the tabs will adjust to that change.

[bpasero]

Pushed this (will be in tomorrows insider release). A new setting workbench.editor.tabSizing is added with values fit and shrink. Set it to shrink to get the behaviour as outlined in #15048 (comment)

[Tekbr]

-- Sorry for the English, I used Google Translator --

@bpasero An idea ... Instead of using the '...', why not use the style of Microsoft Edge, Mozilla Firefox and Google Chrome? 😉 The text is below the "X" (erased slightly) as the guide decreases.

Particularly, I prefer the style of Firefox.

[bpasero]

@Tekbr good suggestions. I am not a big fan of how Edge is simply clipping the text at the end of the tab. I really like what Firefox/Chrome are doing with the fading out in the end, if anyone wants to chime in with a reasonable PR (not too crazy, just CSS), feel free.

What I can change though is to not leave the room for the close button. I realized that when shrinking is enabled, the close button should only show up on hover, but otherwise not consume any space:

I pushed that via d6cb7ab

[Tekbr]

-- Sorry for the English, I used Google Translator --

@bpasero Thanks for the feedback!!

I was happy with your move !! 😄 👏 👏

By your comment it seems like something simple to do (or not) 🤔 , but after going through the team tests .. or even before (if you think better) maybe crawl for a new case suggesting for beginners, no? Referring to this case and the test case, with my comment and your comment (if you think you should). That way, someone can locate it more easily! 🤔

Anyway, thanks again for the feedback! 👍

[bpasero]

Sure, feel free to create a new issue for it and we can ask for help.

[gnowland]

Not sure if I should open a new issue for this, but would it be possible to show the full tab on mouse-over (hover) of an individual tab while keeping the others shrinked? I love the condensed "shrink" view but I've hit a problem when in some projects I can't see but a couple letters of a filename and multiple files start with the same letter! Showing just the hovered tab full-width would allow users to quickly scan over the tabs and switch to the desired one lightning-fast.

Salud!

[bpasero]

@gnowland there is always a hover showing up for a tab after a moment with the full path, right?

[gnowland]

Full path hover? Yes. But that's hardly decent ux. I've never developed for vscode before but I'll take a crack at a PR as an example of what I have in mind.