remove arbitrary 600 pixel limit on quick input widget

[Derek Scherger (dscherger)]

Add maximumWidth and relativeWidth settings to customize width of quickInput widget rather than the hardcoded minimum of 62% of available width or 600 pixel max width

This PR fixes #85374

[Christof Marti (chrmarti)]

Derek Scherger (@dscherger) Wouldn't this make it super-wide on wide screens? I think there is value in having it "in the middle" for easier reading and visual appeal.

[Derek Scherger (dscherger)]

Hi Christof Marti (@chrmarti) thanks for looking at this!

It does make the quick input widget 75% of the width of the vscode window, still "in the middle" of the window but wider than it is now. Perhaps 75% is too much but for projects with the unfortunate combination of long (40-50 chars), non-unique file names and with paths that have the distinguishing element somewhere beyond the 30 character mark there's currently no way to see which variant of a file to open.

I'm sure there other are changes that could be made to solve this problem but it has been reported several times as #38225, #85374, #90948, #100214 and it would be nice to have a workaround in the meantime.

Other Solutions:

• display the full path of the currently selected item somewhere else (tool tip, bottom of window, etc.) without length constraints
• move the ... from the end of the displayed path to the front, so that trailing distinguishing elements can be displayed (may fail depending on where the unique element is)
• remove display of the filename from the front of the path and display the full path (may still fail for long paths)
• allow left/right scrolling of the content within the quick picker to help with navigation & selection (probably the best solution for very long paths)
• allow the quick picker to resize dynamically to fit the full path of the currently available elements (may still fail for very long paths)

Improvements to this Solution:

We could preserve the current look by default and add settings to control both the max width (default to 600px but allow unlimited) and the scale factor (defaulted to 62% but allow for 100%). This would allow people who need it to deal with the problem and not affect anyone who doesn't. Of course this may still fail for really long paths but it will handle less extreme situations a little better than they are now.

[Deleted user (ghost)]

All CLA requirements met.

[TylerLeonhardt]

Thank you so much for this!

Although the settings are a solution, I don't think they're the best solution for this task. I'd prefer to see the quick input dynamically expand with the size of the content or allow it to be resized.

I think we'll want to revisit this when we look at the new "omnibar" experience detailed in #115641

[an-dr-eas-k]

This is a fairly minor change that replaces the customize-ui workaround for many users (with all its security implications). The merge broadens the user-base that will give feedback, maybe also usable for the future omnibar.

[Pavlo Kashko (PalGenadich)]

Isidor Nikolic (@isidorn) Please push this through. This was my case for using Customize UI. And since 1.74 it's no longer viable iocave/customize-ui#156

[Silviu (Moghul)]

Christof Marti (@chrmarti) Aesthetics are important but not to the degree that they get in the way of functionality. If I can't use the tool well, it doesn't matter to me how pretty it is.

Derek Scherger (@dscherger) Thank you very much for the PR, I look forward to it being merged! The only thing I mildly disagree with is the equally arbitrary 2000 maximum limit. Just let me set it to what I want. If it breaks because the number's too big, the settings can always be changed back.

[Derek Scherger (dscherger)]

Christof Marti (@chrmarti) Aesthetics are important but not to the degree that they get in the way of functionality. If I can't use the tool well, it doesn't matter to me how pretty it is.

Derek Scherger (@dscherger) Thank you very much for the PR, I look forward to it being merged! The only thing I mildly disagree with is the equally arbitrary 2000 maximum limit. Just let me set it to what I want. If it breaks because the number's too big, the settings can always be changed back.

Christof Marti (@chrmarti) Silviu (@Moghul)
This is definitely a "perfect is the enemy of the good" type of situation. It's been over 2 years since I put up the original fix and I'd be really curious to know how many people would have benefitted from it over that time while we're waiting for omnibar perfection. I haven't read the latest comments in #115641 and don't have any sense of whether this is close to landing or if it will ever land.

As far as the arbitrary 2000 character limit goes, I'm not sure if this is a required value in the config or whether it can be left out entirely. It looks like I need to go resolve some conflicts and I'll have a look at the limit while rebasing.

[nschikora]

Adding a screenshot here as well to make clear what this is about. The paths in the project I’m working on are not too deep but still line 3 and 4 are indistinguishable from each other. (One is an interface and the other the implementation). I run into this few times a day.

[Johnny Oshika (johnnyoshika)]

Here's an example why this enhancement is desperately needed

[Silviu (Moghul)]

What exactly has to happen for this to be merged and released? It seemed like such a slam dunk, but it's been 3 years.

[R.G. (protoEvangelion)]

Aiday Marlen Kyzy (@aiday-mar) Johannes Rieken (@jrieken) Aaron Munger (@amunger) Megan Rogge (@meganrogge) Connor Peet (@connor4312) What needs to be done to get this merged? Pinging you because you are the top 5 contributors in the last month, we haven't heard back from maintainers in over 3 years, & there is overwhelming community desire for this. FYI, this small PR would solve my #1 gripe with VSCode: I cannot quick search my files because I cannot see the full path 99% of the time.

[Johnny Oshika (johnnyoshika)]

I would desperately love this as well 🙏

[Johnny Oshika (johnnyoshika)]

This is desperately needed. When working in a large monorepo with deeply nested files, the 600px limit is very restrictive.

[Vincent Cuenca (vecuenca)]

This would be a huge QOL improvement! 😀

[Daniel Imms (Tyriar)]

TylerLeonhardt I've tested this and it works well, I think we should move forward and merge it instead of waiting for the ideal solution. If we do end up getting dynamic sizing happening we can always remove these settings at that point.

[R.G. (protoEvangelion)]

Tested and works as expected:

BEFORE

AFTER

[R.G. (protoEvangelion)]

Daniel Imms (@Tyriar) are we ready to rock on this?

[Daniel Imms (Tyriar)]

R.G. (@protoEvangelion) spoke with some people in the team and we're a little concerned about adding a setting that will just get deleted. I think the way forward here is to allow the user to resize this by using a Sash on the right side of the quick pick.

You can see a similar interaction in "quick chat" if you have copilot installed:

We would then just want it to be horizontal. How this gets persisted is a bit of an unknown to me still, but my guess is maybe we want to store it in the percentage-based value and do away with the pixel one all together? So most users will configure it purely through the mouse interaction.

[an-dr-eas-k]

Great Idea Daniel Imms (@Tyriar). While imo the suggestion of TylerLeonhardt from 2021 is even superior, see #117862 (comment)

For me it seems, there are so many people requiring this feature which is ready to be released and has comparably low code change (to be taken out later).

Having it for a start allows a longer process of thorough and stress-free planning and choosing the alternatives.

So please lets get moving here and support us developers out there.

[Johnny Oshika (johnnyoshika)]

I desperately need this. If we can push out a temporary fix, it would be such a QOL improvement. I've been dealing with this pain in my large monorepo for over 3 years. Having come from Visual Studio IDE (which allows resizing of the command palette), this has been a tough adjustment.

[Wojciech Adamczyk (wadamczyk-insolutions)]

Is there any way we can help push this forward? This issue is currently very frustrating for our projects. From what I understand, the only remaining step is obtaining Community PR Approvals. Could you explain the process for this? Is there any way to expedite these approvals?

[vivodi]

Is this still relevant?

[Silviu (Moghul)]

Is there any reason this wouldn't be relevant? Did a feature come out to make this irrelevant? Have all monorepos been deprecated?

[Q-back (Q-back)]

It's 2025 now, let's sum up where we are.
This fix was introduced ~4 years ago, the issue is still there.
This solution was proven to fix the issue.
It was rejected because there are potentially better solutions (e.g. the omnibar that was never merged as well since 2021).
Also, maintainers are worried about introducing changes that would be later deleted.
Although these changes would stay here 4 years if they'd merged back in 2021.

So with that in mind maybe it would be best to merge it despite everything because other solutions did not work anyway.

These settings would help many people.
If these settings will be experimental you don't need to sorry anyone for deleting them later when something better drops.

[Oleh Vdovenko (olhapi)]

This should be done years ago.

[Brent Jubinville (utilityboy)]

There is now the ability to position / drag & drop the quick input around as of 1.97.0. I would be curious to see the metrics to understand the importance of this enhancement vs. the option to adjust the width.

[Silviu (Moghul)]

Personally, I could not care less where the menu is, I guess I wouldn't have it on the right.
But this feature... To me, it's mandatory, and it's not there. It's been long enough that I might start looking at another IDE.

[1803200]

[Oleh Vdovenko (olhapi)]

There's clearly a prioritization issue. 600px wide quickInput looks especially great on a 4k or ultra wide displays.

[Wojciech Adamczyk (wadamczyk-insolutions)]

Come on. There are just 24 changed lines waiting to be reviewed — it can't really be that hard, can it? It's mildly infuriating to have to edit the CSS files by hand after every Visual Studio Code update just to fix this. Meanwhile, the ability to change the input widget's position has somehow made it into a release. Does anyone know who can be pinged to finally close this issue?

[wolfsilver]

Come on. There are just 24 changed lines waiting to be reviewed — it can't really be that hard, can it? It's mildly infuriating to have to edit the CSS files by hand after every Visual Studio Code update just to fix this. Meanwhile, the ability to change the input widget's position has somehow made it into a release. Does anyone know who can be pinged to finally close this issue?

Use https://marketplace.visualstudio.com/items?itemName=be5invis.vscode-custom-css, you can do almost anything you want!

[Élise (MasterInQuestion)]

    In fact it should just be:
    min-width: min( 600px, 62% ); max-width: 90%;
    .
    But seems the "flex" layout in its child elements glitched somehow:
    Not properly reflects the filenames width.
    (flexbox layout in CSS seems to be generally broken; use "<table>" instead?)

    Exemplar very lengthy filename for test:
    123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345
    (255 characters)

[Wojciech Adamczyk (wadamczyk-insolutions)]

Well, come on! What can be done to get this finally fixed after so many years? It's a simple task! I'm happy to help... it's so frustrating to still need to change the CSS manually after every update and have VS Code complain it's corrupted after every restart...