@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.

Hi @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.

All CLA requirements met.

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

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.

@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

@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.

@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.

@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.

@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.

@chrmarti @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.

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.

Here's an example why this enhancement is desperately needed

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.

@aiday-mar @jrieken @amunger @meganrogge @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.

I would desperately love this as well 🙏

The quick input is really useless in my repo for finding files without this change since everything is so deeply nested and I can’t see the paths. VS Code core team—please merge this!!

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

This would be a huge QOL improvement! 😀

@Tyriar are we ready to rock on this?

@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.

Great Idea @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.

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.

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?