Add setting items to control items in status bar

[TerminalFi]

Release Notes:

Added settings

• show_status_bar for hiding the status bar
• show_active_language for hiding the active language in the status bar
• show_cursor_position for hiding the cursor position
• show_feedback_icon for hiding the share feedback button

Added button properties to other status bar items to hide.

- Added new settings object that controls various elements in status bar

  "status_bar": {
    "visible": true,
    "elements": {
      "project": false,
      "assistant": false,
      "feedback": false,
      "terminal": false,
      "copilot": false,
      "cursor_position": false,
      "language_selector": false,
      "chat": false,
      "notification": false,
      "collaboration": false,
      "diagnostics": false
    }
  }

The only thing I do not like is that assistant_panel copilot, etc all have settings like the below

"assistant": {
    "button": false
  },

This seems like now we would have 2 different places to contain status bar items

Preview

https://github.com/zed-industries/zed/assets/32599364/e605d6bd-6c9b-442b-bc8b-4591ce5796f6

closes https://github.com/zed-industries/zed/issues/8169

[cla-bot[bot]]

We require contributors to sign our Contributor License Agreement, and we don't have @TerminalFi 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'.

[TerminalFi]

@cla-bot check

[cla-bot[bot]]

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

[TerminalFi]

The other options is to call this UiSettings

And then we can merge any UI element through this setting object. Such as title bar, etc

[slymax]

What about a structure like this:

"status_bar": {
  "visible": true,
  "elements": {
    "assistant": true,
    "feedback": true
  }
}

this would make it a bit more structured, especially in case this gets wrapped in a workspace_settings property (or something like that) in the future

and yeah I think the duplicate settings should be removed before this gets added

[wmstack]

Hmm any way to order the elements?

[slymax]

Hmm any way to order the elements?

good question. I think someone from the team should chime on whether the order should be customizable

[probablykasper]

Seems fair to have the order customizable.

"status_bar": {
  "visible": true,
  "elements": [
    "assistant",
    "feedback",
    "etc"
  ]
}

[TerminalFi]

Just stating, this is outside the scope of what I am working on. As reading the code, I elieve it would require some rework.

Seems fair to have the order customizable.

"status_bar": {
  "visible": true,
  "elements": [
    "assistant",
    "feedback",
    "etc"
  ]
}

this doesn't handle if it is left or right side of the status bar. Which is also needed. I think this would be out of scope for this PR. Is there a issue for this already?

[probablykasper]

It might be something to consider so that it won't be necessary to do a settings migration (but that's not my decision ofc)

[TerminalFi]

I'm not sure combining these under a single status_bar config is the way to go.

I think we might want to keep them nested under their respective sections, so that each component is somewhat independent.

This will be more important in the future when extensions expose their own settings.

Sure, I can take another stab at it. Moving things back under specific scopes

What able for the general status-bar ?

Should it still be status_bar: { visible: true } or just a single top level key value like show_status_bar: true

[TerminalFi]

@maxdeviant The only thing I can't figure out is hiding the Copilot icon. The code I put doesn't seem to work... any ideas?

Also, I put the show_ ones at the workspace level...because I don't know that sections for those exist or even make sense.

If you really want sections for each of those. I can add them

[TerminalFi]

Could probably put cursor position and active language in editor settings

[maxdeviant]

Apologies for the radio silence here.

I think the surface area for this PR is a bit too large at the moment. Maybe we could try opening up smaller PRs for each individual new setting?

[TerminalFi]

Apologies for the radio silence here.

I think the surface area for this PR is a bit too large at the moment. Maybe we could try opening up smaller PRs for each individual new setting?

Sure!