Tab wrap - implement different presentation so that tabs don't jump around (editor actions, decorations, dirty state)
Opened this issue · 15 comments
@eamodio what would you suggest in this case? I think this is just a consequence of us having dynamic actions in the editor toolbar. The only way out I see is to not do that and keep editor actions in a toolbar in a different place?
Yeah, not sure -- maybe something like reserve a certain amount of space for the actions so they can grow without wrapping the tabs as least until some threshold? I dunno.
Alternatively -- if bookmarks are visible, it would be nice to have the actions moved down to the "empty" right side.
if bookmarks are visible
Can you clarify, what are bookmarks in the context of VSCode?
maybe something like reserve a certain amount of space for the actions so they can grow without wrapping the tabs as least until some threshold?
One idea I had was to simply never hide the actions when a group is inactive, but in fact this was not possible because actions are context key aware and some are only contributed when the group is active.
Doh, I meant breadcrumbs
Somehow I feel breadcrumbs belong more into the editor and are part of the editor than the tab and the editor actions, but it is an interesting idea.
Is there some way to check how many actions will be shown for each file in the group? Then space could be reserved for the worst case in the group?
I've been annoyed by this behavior for quite a long time, routinely apply the trick #46403 (comment) every restarts of the IDE.
Now I think maybe we can have a setting to request a fixed number of rows of tabs, then extraneous tabs go into a "..." drop down, as well as extraneous action-icons go into another "..." drop down. It should never "jump" again.
The fixed number of rows in each area, ideally can be ad-hoc manipulated by DnD gestures.
Tab wrap is a frequently used feature, and the implementation in VS Code is quite substandard. There can not be any jumping around in the text editor position. This happens even when the editor is focused and getting typed into, as source control/git scans the files in the background, it adds and removes "Editor Actions", the tabs, the editor position jump around and have a mind of their own...
These "Editor Actions" need to have their own area or row. They belong to a single file, not to a collection of files and tabs. So it is a confusing design that they share that space anyway, besides the unstable positioning and interference with usability.
Sharing the right side of the breadcrumb area is not a bad idea, as the breadcrumb belongs to a single file as well. Being able to turn them off completely, or always show the fixed ... menu should be another option.
Totally agree with @BukeBeyond. The actions totally belong to the current file, not to the tab collection.
There is a frequently visted thread on StackOverflow on this topic which shows that it is bugging quite a lot of users.
I managed to move the action buttons to the breadcrumb bar using the Customize UI extension (find my code and vote for it here on StackOverflow) and can confirm that this results in a way better user experience:
Only drawback is that the buttons overlap the breadcrumbs if they get long, so I would definitely prefer a native solution instead of this hacky workaround.
Hi Devs,
is there an Update on this one?
I started using VS Code and I find it really annoying as mentioned above a few times.
So I will definitly watch this issue from now on. Hopefully it gets more attention.
At least for the editor actions you can decide to show them in the title bar or hide them which will avoid the issue of jumping wrapped tabs at least for when actions change:
This feature can be tried out in our insiders build: You can give our preview releases a try from: https://code.visualstudio.com/insiders/
//cc @benibenj for enabling this capability
Thanks, for the hint. This will be a step forward.
Any update here? This has been open for almost 3 years now.
I realize there is a workaround, but I do not want to have to install the insiders build just to achieve this, and it seems that the extension workaround may require re-enabling the extension every time VSCode is relaunched - both of which are cumbersome.
Everything we have in insiders gets into stable on the next release, so you should be good to go with the workaround at least.