Add width setting for the file finder

[isaacdonaldson]

This PR adds the ability to adjust the width of the file finder popup. I found when searching my projects the default width was not always wide enough and there was no option to change it.

It allows values small, medium (default), large, xlarge, and full

Release Notes:

• Added a setting to adjust the width of the file finder modal

Example Setting:

  "file_finder": {
    "modal_width": "medium"
  },

Screenshots can be found in the comments below.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @isaacdonaldson on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[isaacdonaldson]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[thorbenk]

See

• File finder width can be too small to disambiguate files #16018

[isaacdonaldson]

See #16018

Ah my apologies, I looked for a past issue and couldn't find one, so I missed this one. This PR would solve the issue of not being able to configure the width of the file finder that is mentioned there too.

[danilo-leal]

Very cool—thanks for the PR! I have a feeling it could make sense to tokenize the width value as opposed to being just an arbitrary number. We do already have compact, comfortable, and default as tokens that represent density (see #18078), which we could possibly be used here, too, but I'm not sure yet.

Also, this doesn't necessarily mean that we wouldn't continue to allow passing arbitrary numbers—it's just so that there's a set of pre-established defaults that the whole app follows when it comes to UI config.

cc @iamnbutler for further thoughts!

[maxdeviant]

I think we may want to make the default behavior to have the modal size itself more intelligently to fit the available space rather than jumping to making the width configurable.

[isaacdonaldson]

I think we may want to make the default behavior to have the modal size itself more intelligently to fit the available space rather than jumping to making the width configurable.

@maxdeviant Yeah I agree. I changed it to have 4 width settings: "small" | "medium" | "large" | "xlarge" where "medium" is the default. The settings correspond to how much padding is on the side of the popup ("small" will have the largest padding). There is also a minimum width for the window so it will work fine on very small screens.

Screenshots:

Small:

Medium:

Large:

XLarge:

Here is the behaviour when the window is shrunk with the "xlarge" setting:

large_shrink.mov

And when it hits the minimum size:

small_shrink.mov

And finally, what the "xlarge" setting looks like when in a small window:

[alejandrovrojas]

I changed it to have 4 width settings: "small" | "medium" | "large" | "xlarge" where "medium" is the default.

@isaacdonaldson This could be a good opportunity to implement full as well!

[isaacdonaldson]

@alejandrovrojas - I added the "full" option for a fullscreen width finder window.

Maybe someone from Zed can let me know if there are any desired changes, or if there is anything holding this PR up?

[thorbenk]

I tried this branch and I like it! It solves my problem #16018

Thanks @isaacdonaldson, I hope this gets in 😄

[protoEvangelion]

@maxdeviant @ConradIrwin @mrnugget I'll literally switch from VSCode to Zed over this issue. It's been 3 years & they are still debating on how to allow users to override width: microsoft/vscode#117862
Is there anything else that needs to be done on this PR to push it through?

[SomeoneToIgnore]

This actually looks good, not sure why it got stalled.

Can we rebase and, optionally, add an entry to https://github.com/zed-industries/zed/blob/516f7b364213b2bbc1a658295df96443aa885ca0/docs/src/configuring-zed.md ?

And we're good to merge right after.

Edit: + Danilo's review comment is needed before the merge.

[isaacdonaldson]

@SomeoneToIgnore - Sounds good, easy changes

[SomeoneToIgnore]

Thank you!

[dangh]

It's might be too late to comment on this but I think computing the modal width by subtracting the paddings is not intuitive as it makes the modal "small" compare to the window, not the screen. On my mac, "small" modal is to wide on full screen width (takes too much of screen real estate and too wide compare to the command palette), and "medium" too small on half screen width (my paths are cut-off too much), which is very confusing.

Generally we want to define the minimum width of the modal so it can show long paths. If the modal is too wide for the small window, we shrink the modal so it can fit. An arbitrary number can help fine-tuned the setup for everyone that use more than one screens.

Also a nitpicking but I would add small x-padding to the "full" modal as it has shadow and rounded corners, it would looks better this way.

@danilo-leal may I have your input on this?

[xzbdmw]

we can show full content when hovering or just selecting over long strings as JetBrains does:

iShot_2024-11-30_03.26.17.mp4

This logic is applied consistently throughout the entire IDE.