You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I implemented sidebar optimal resizing in 65bdaf3. However some desirable characteristics of this feature were postponed due to some implementation challenges—namely, measuring not-yet-rendered DOM elements. I’m opening this issue to keep track of these sub-features with the hope that they will be solved at some point.
getOptimalWidth() doesn’t work if the sidebar is closed, ie you can’t double click on the closed sash to open the sidebar to its optimal width, which is expected;
if the explorer list is too long, VSCode renderer will break the list into multiple “tiles” that won’t be displayed concurrently, thus getOptimalWidth() will only consider visible elements and not the entire list. For comparison, this is handled correctly by both Atom and SublimeText.
The text was updated successfully, but these errors were encountered:
This feature request will not be considered in the next 6-12 months roadmap and as such will be closed to keep the number of issues we have to maintain actionable. Thanks for understanding and happy coding!
I implemented sidebar optimal resizing in 65bdaf3. However some desirable characteristics of this feature were postponed due to some implementation challenges—namely, measuring not-yet-rendered DOM elements. I’m opening this issue to keep track of these sub-features with the hope that they will be solved at some point.
(originate from #4702 (comment))
getOptimalWidth()
doesn’t work if the sidebar is closed, ie you can’t double click on the closed sash to open the sidebar to its optimal width, which is expected;getOptimalWidth()
will only consider visible elements and not the entire list. For comparison, this is handled correctly by both Atom and SublimeText.The text was updated successfully, but these errors were encountered: