Closes#10232
Context:
We have three ways to open files or dirs in Zed: `zed`, `zed --new`, and
`zed --add`. `--new` forces the project to open in a new window, while
`--add` forces it to open in an existing window (even if the dir isn’t a
subdir of an existing project or the file isn’t part of it).
Using just `zed` tries to open it in an existing window based on similar
logic of `--add`, but if no related project is found the dir, opens in a
new window.
Problem:
Right now, subdirs that are part of an existing project open in the
existing window when using `zed`. By default, subdirs should open in a
new window instead. If someone wants to open it in the existing window,
they can explicitly use `--add`. After this PR, only root dir and files
will focus on existing window, when `zed ` is used.
Fix:
For the `zed` case, we’ve filtered out subdirs in the logic that assigns
them to an existing window.
Release Notes:
- Fixed an issue where subdirectories of an already opened project, when
opened via the terminal, would open in the existing project instead of a
new window.
This PR adds support for configuring both a light and dark icon theme in
`settings.json`.
In addition to accepting just an icon theme name, the `icon_theme` field
now also accepts an object in the following form:
```jsonc
{
"icon_theme": {
"mode": "system",
"light": "Zed (Default)",
"dark": "Zed (Default)"
}
}
```
Both `light` and `dark` are required, and indicate which icon theme
should be used when the system is in light mode and dark mode,
respectively.
The `mode` field is optional and indicates which icon theme should be
used:
- `"system"` - Use the icon theme that corresponds to the system's
appearance.
- `"light"` - Use the icon theme indicated by the `light` field.
- `"dark"` - Use the icon theme indicated by the `dark` field.
Closes https://github.com/zed-industries/zed/issues/24695.
Release Notes:
- Added support for configuring both a light and dark icon theme and
switching between them based on system preference.
Closes https://github.com/zed-industries/zed/issues/23894
Reworks all trigger declarations from
`.trigger(element.tooltip(tooltip))` into
`.trigger_with_tooltip(element, tooltip)` , with new API disallowing
simultaneous trigger and tooltip display.
All existing `.trigger(` calls were replaced, except 2 not applicable
(in dock.rs and pane.rs), 15 left as ones without tooltips, and 2
unchanged places in `inline_completion_button.rs`, where
0f7bb2e9fd/crates/inline_completion_button/src/inline_completion_button.rs (L311-L319)
`with_animation` does not allow us to simply use the same approach.
Release Notes:
- Fixed hover tooltips appearing after related element is pressed
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This PR formalizes design components with the Component and
ComponentPreview traits.
You can open the preview UI with `workspace: open component preview`.
Component previews no longer need to return `Self` allowing for more
complex previews, and previews of components like `ui::Tooltip` that
supplement other components rather than are rendered by default.
`cargo-machete` incorrectly identifies `linkme` as an unused dep on
crates that have components deriving `IntoComponent`, so you may need to
add this to that crate's `Cargo.toml`:
```toml
# cargo-machete doesn't understand that linkme is used in the component macro
[package.metadata.cargo-machete]
ignored = ["linkme"]
```
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Closes#22247
- [x] Do not close pinned tab on keyboard shortcuts like `ctrl+w` or
`alt+f4`
- [x] Close pinned tab on context menu action, menu bar action, or vim
bang
- [x] While closing pinned tab via shortcut (where it won't close),
instead activate any other non-pinned tab in same pane
- [x] Else, if any other pane contains non-pinned tab, activate that
- [x] Tests
Co-authored-by: uncenter <47499684+uncenter@users.noreply.github.com>
Release Notes:
- Pinned tab now stay open when using close shortcuts, auto focuses to
any other non-pinned tab instead.
- [x] snake case keymap properties
- [x] flatten actions
- [x] keymap migration + notfication
- [x] settings migration + notification
- [x] inline completions -> edit predictions
### future:
- keymap notification doesn't show up on start up, only on keymap save.
this is existing bug in zed, will be addressed in seperate PR.
Release Notes:
- Added a notification for deprecated settings and keymaps, allowing you
to migrate them with a single click. A backup of your existing keymap
and settings will be created in your home directory.
- Modified some keymap actions and settings for consistency.
---------
Co-authored-by: Piotr Osiewicz <piotr@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
- Adds the `panel` crate for defining UI shared between panels, like
common button and header designs, etc
- Starts to update the git ui to be more consistent with other panels
Release Notes:
- N/A
This PR makes adding icons to the primary and secondary actions, in the
`MessageNotification` component, optional. Also took the opportunity to
remove a probably unnecessary "third action" from it; streamlining the
component API (we had added that for a design that we're not using
anymore). I did keep the "more info" possibility, which may be useful in
the future, though.
Release Notes:
- N/A
This long standing bug was caused by `Pane`'s focus_in handler bouncing
the focus to another handle.
Because focus resolution happens _after_ a frame has been rendered, the
only way to deal with this case is to schedule another frame to be
redrawn. However, we where suppressing all window refreshes that occur
during a focus transfer, causing this focus change to be completely
missed. However, changing this behavior can lead to infinite notify
loops, due to drawing a frame causing another to be rendered.
This PR fixes this problem narrowly by adding an `on_next_frame()`
callback in the pane's focus handle, so that the focus changes take
effect almost immediately. But only for this case, where we know it
doesn't cause infinite notify loops.
TODO:
- [x] Fix the infinite notify loop bug or determine a third way to fix
this lag
Release Notes:
- Fixed a bug where shifting focus to the terminal panel could be slow
## Context
While looking through the client crate, I noticed that some of the old
functions and variables were still using gpui::model name that was
deprecated during the gpui3 transition. This PR renames those instances
of model to entity to be more inline with gpui3.
In addition, I also renamed `model` to `entity` in cases found by the
below search terms given by @someone13574
- model = cx.
- model: Entity
- model: &Entity
- OpenedModelHandle
- model.update
- model.upgrade
- model = .*\.root (regex)
- parent_model
- model = cx.new
- cx.spawn(move |model
Release Notes:
- N/A
I believe this takes care of the remaining events running through the
old flow that requires transformation at the collab server level. I
think all events are now going through `telemetry::event!()`.
For anyone curious where the new telemetry names are coming from, you
can check the `for_snowflake` function within
`crates/collab/src/api/events.rs`, to see how collab is currently
transforming the events going through the old flow.
Release Notes:
- N/A
In the left hand status bar, there are two groups of buttons. There was
a border between the two hardcoded on the first button of the second
group, however, if all buttons in the first group are hidden, the border
doesn't need to be rendered.
(Not handled in this PR) A potentially better approach would be to
change StatusBar's definition from `left_items` and `right_items` to
`left_groups` and `right_groups`, and render dividers between each group
of items. That seemed like a bigger refactor than I wanted to handle for
now, but is an option for the future.
If you use these settings on `main`, the border will show, but with
nothing to the left of it.
```json
{
"collaboration_panel": {
"button": false
},
"outline_panel": {
"button": false
},
"project_panel": {
"button": false,
},
}
```
Screenshots:
Before:
<img width="117" alt="Screenshot 2025-02-02 at 6 19 24 PM"
src="https://github.com/user-attachments/assets/b3401b47-6172-4392-9277-31aa1affaf7a"
/>
<img width="134" alt="Screenshot 2025-02-02 at 6 20 12 PM"
src="https://github.com/user-attachments/assets/1e8caee6-1da8-47f6-8499-9a93b6d8fa27"
/>
After:
<img width="125" alt="Screenshot 2025-02-02 at 6 19 58 PM"
src="https://github.com/user-attachments/assets/9b9f421c-660b-41cb-80e0-acb774c66054"
/>
<img width="132" alt="Screenshot 2025-02-02 at 6 20 20 PM"
src="https://github.com/user-attachments/assets/87e0e475-084b-44df-b820-573c68728c1a"
/>
Release Notes:
- Conditionally render divider in status bar
---------
Co-authored-by: Danilo Leal <67129314+danilo-leal@users.noreply.github.com>
Closes#23334
This does not follow the exact way that windows are resized in vim.
Normally the command is `ctrl-w >` however this PR uses just `ctrl->`.
This is because I could not find a good way to read in a count like `10
ctrl-w ctrl->`. This is not really a problem since `ctrl->` can be held
down, which, in my opinion, speeds up resizing. I think this is a good
compromise since it improves usability; however, I am concerned that
this is not intuitive. I am looking forward to feedback.
Release Notes:
- Added the following commands
- vim::ResizeLeftDock
- vim::ResizeRightDock
- vim::ResizeBottomDock
- Added keybinds
- `ctrl->` for widening left dock
- `ctrl-<` for narrowing left dock
TODO:
- [x] BackgroundOrientation
- [x] PatternDash
- [x] `pattern_horizontal_dash` & `pattern_vertical_dash`
- [x] Metal dash shader
- [x] Blade dash shader
- [x] Update ui::Divider to use new pattern
---
This PR introduces proper dashed dividers using the new `PatternDash`
background shader.
Before this we were using 128 elements to create a dashed divider, which
is both expensive, and would not scale beyond a certain size. This
allows us to simplify the divider element as well.
Changes:
- Adds `BackgroundOrientation` to `gpui::color::Background` to allow
specifying a direction for a pattern
- Adds the PatternDash pattern variant
- Updates `ui::Divider`'s dashed variants to be more efficient
Misc:
- Documents the `ui::Divider` component
- Treat `.metal` files as `C` in the Zed project until we get some metal
syntax highlighting.
Release Notes:
- N/A
Required using a global `LazyLock<Mutex<AppNotifications>>` instead of a
context global because settings errors first occur before initialization
of the notifications global.
Release Notes:
- Errors in settings file are now reported in UI on startup.
Closes#21625#17401#16426
This is how the opening of a file works currently:
1. We first check if the file is part of any existing worktree. If it
is, we focus on that file in the worktree, and the window is activated.
2. If the file is not part of any worktree, we open it in the first
local non-collab workspace we find and activate that window. This is the
bug that the issues are based on.
This PR fixes it by modifying the second part of the above step, where
the file is not part of any worktree. Now, we will first open the file
in the active window, but only if the active window is local and
non-collab. This resolves the issue. If the file can't be opened in the
active window due to the local non-collab check, we will carry out the
existing logic of opening the file in whichever window is local and
non-collab.
I have tested this using the "workspace::OpenFiles" action, and
"workspace::Open" also uses the same method. That is, it will work on
all platforms.
Future: Some users also mentioned there should be a setting for whether
we should open a non-workspace file in the existing window or in a
separate new window. However, this seems out of scope, and a new issue
should be created for this.
#9370 is related, but this likely doesn't fix it, as it deals with how
macOS Finder's "Open with" handles files. I don't have macOS to test,
but this PR won't resolve it if Finder always opens a new window.
Release Notes:
- Fixed the issue where a file outside of the workspace was opening in a
random window instead of the last active window.
This PR adds the `show_tab_bar_buttons` under `tab_bar` that allows
hiding the "New", "Split Pane", and "Zoom" buttons to the left of the
pane tab bar.
Release Notes:
- Added a new `show_tab_bar_buttons` setting, under `tab_bar`, that
enables hiding the pane tab bar buttons.
Fix bugs caused by the window context PR, where the window could be on
the stack and is then requested from the App.
This PR also adds derive macros for `AppContext` and `VisualContext` so
that it's easy to define further contexts in API code, such as
`editor::BlockContext`.
Release Notes:
- N/A
Fix a bug where a GPUI macro still used `ModelContext`
Rename `AsyncAppContext` -> `AsyncApp`
Rename update_model, read_model, insert_model, and reserve_model to
update_entity, read_entity, insert_entity, and reserve_entity
Release Notes:
- N/A
There's still a bit more work to do on this, but this PR is compiling
(with warnings) after eliminating the key types. When the tasks below
are complete, this will be the new narrative for GPUI:
- `Entity<T>` - This replaces `View<T>`/`Model<T>`. It represents a unit
of state, and if `T` implements `Render`, then `Entity<T>` implements
`Element`.
- `&mut App` This replaces `AppContext` and represents the app.
- `&mut Context<T>` This replaces `ModelContext` and derefs to `App`. It
is provided by the framework when updating an entity.
- `&mut Window` Broken out of `&mut WindowContext` which no longer
exists. Every method that once took `&mut WindowContext` now takes `&mut
Window, &mut App` and every method that took `&mut ViewContext<T>` now
takes `&mut Window, &mut Context<T>`
Not pictured here are the two other failed attempts. It's been quite a
month!
Tasks:
- [x] Remove `View`, `ViewContext`, `WindowContext` and thread through
`Window`
- [x] [@cole-miller @mikayla-maki] Redraw window when entities change
- [x] [@cole-miller @mikayla-maki] Get examples and Zed running
- [x] [@cole-miller @mikayla-maki] Fix Zed rendering
- [x] [@mikayla-maki] Fix todo! macros and comments
- [x] Fix a bug where the editor would not be redrawn because of view
caching
- [x] remove publicness window.notify() and replace with
`AppContext::notify`
- [x] remove `observe_new_window_models`, replace with
`observe_new_models` with an optional window
- [x] Fix a bug where the project panel would not be redrawn because of
the wrong refresh() call being used
- [x] Fix the tests
- [x] Fix warnings by eliminating `Window` params or using `_`
- [x] Fix conflicts
- [x] Simplify generic code where possible
- [x] Rename types
- [ ] Update docs
### issues post merge
- [x] Issues switching between normal and insert mode
- [x] Assistant re-rendering failure
- [x] Vim test failures
- [x] Mac build issue
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Joseph <joseph@zed.dev>
Co-authored-by: max <max@zed.dev>
Co-authored-by: Michael Sloan <michael@zed.dev>
Co-authored-by: Mikayla Maki <mikaylamaki@Mikaylas-MacBook-Pro.local>
Co-authored-by: Mikayla <mikayla.c.maki@gmail.com>
Co-authored-by: joão <joao@zed.dev>
Closes#12553
* [x] Fix `diff_hunk_before`
* [x] Fix failure to show deleted text when expanding hunk w/ cursor on
second line of the hunk
* [x] Failure to expand diff hunk below the cursor.
* [x] Delete the whole file, and expand the diff. Backspace over the
deleted hunk, panic!
* [x] Go-to-line now counts the diff hunks, but it should not
* [x] backspace at the beginning of a deleted hunk deletes too much text
* [x] Indent guides are rendered incorrectly
* [ ] Fix randomized multi buffer tests
Maybe:
* [ ] Buffer search should include deleted text (in vim mode it turns
out I use `/x` all the time to jump to the next x I can see).
* [ ] vim: should refuse to switch into insert mode if selection is
fully within a diff.
* [ ] vim `o` command when cursor is on last line of deleted hunk.
* [ ] vim `shift-o` on first line of deleted hunk moves cursor but
doesn't insert line
* [x] `enter` at end of diff hunk inserts a new line but doesn't move
cursor
* [x] (`shift-enter` at start of diff hunk does nothing)
* [ ] Inserting a line just before an expanded hunk collapses it
Release Notes:
- Improved diff rendering, allowing you to navigate with your cursor
inside of deleted text in diff hunks.
---------
Co-authored-by: Conrad <conrad@zed.dev>
Co-authored-by: Cole <cole@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Michael <michael@zed.dev>
Co-authored-by: Agus <agus@zed.dev>
Co-authored-by: João <joao@zed.dev>
The keymap error notifications got convoluted to support displaying the
notification on startup. This change addresses it systemically for all
future app notifications.
Reverts most of #20531, while keeping the fix to handle keyboard layout
switching. This is a better fix for #20531
Release Notes:
- N/A
* Remove `NotificationHandle` trait in favor of just passing `AnyView` -
id field wasn't used.
* Remove `show_notification_once`, doesn't seem to be needed for its
only use.
Release Notes:
- N/A
Closes#22740
I haven't assigned any default keybindings to these actions because it
might conflict with existing OS bindings.
Preview:
https://github.com/user-attachments/assets/7c62cb34-2747-4674-a278-f0998e7d17f9
Release Notes:
- Added `workspace::ActivateNextWindow` and
`workspace::ActivatePreviousWindow` actions for cycling between windows.
This Pull Request introduces a new command `workspace: move focused
panel to next position` which finds the currently focused panel, if such
panel exists, and moves it to the next valid dock position, following
the order of `Left → Bottom → Right` and then starting again from the
left position.
In order to achieve this the following changes have been introduced:
* Add a new default implementation for `PanelHandle`, namely
`PanelHandle::move_to_next_position` which leverages
`PanelHandle::position`, `PanelHandle::position_is_valid` and
`PanelHandle::set_position` methods to update the panel's position to
the next valid position.
* Add a new method to the `workspace` module, `
move_focused_panel_to_next_position`, which is responsible for finding
the currently focused panel, if such a panel exists, and calling the
`move_to_next_position` method in the panel's handle.
* Add a new action to the `workspace` module,
`MoveFocusedPanelToNextPosition`, which is handled by the
`move_focused_panel_to_next_position` method.
Tests have also been added to the `workspace` module in order to
guarantee that the action is correctly updating the focused panel's
position.
Here's a quick video of it, in action 🔽https://github.com/user-attachments/assets/264d382b-5239-40aa-bc5e-5d569dec0734Closes#23115
Release Notes:
- Added new command to move the focused panel to the next valid dock
position – `workspace: move focused panel to next position` .
https://github.com/user-attachments/assets/78db908e-cfe5-4803-b0dc-4f33bc457840
* starts to extract usernames out of `users/` GitHub API responses, and
pass those along with e-mails in the collab sessions as part of the
`User` data
* adjusts various prefill and seed test methods so that the new data can
be retrieved from GitHub properly
* if there's an active call, where guests have write permissions and
e-mails, allow to trigger `FillCoAuthors` action in the context of the
git panel, that will fill in `co-authored-by:` lines, using e-mail and
names (or GitHub handle names if name is absent)
* the action tries to not duplicate such entries, if any are present
already, and adds those below the rest of the commit input's text
Concerns:
* users with write permissions and no e-mails will be silently omitted
— adding odd entries that try to indicate this or raising pop-ups is
very intrusive (maybe, we can add `#`-prefixed comments?), logging seems
pointless
* it's not clear whether the data prefill will run properly on the
existing users — seems tolerable now, as it seems that we get e-mails
properly already, so we'll see GitHub handles instead of names in the
worst case. This can be prefilled better later.
* e-mails and names for a particular project may be not what the user
wants.
E.g. my `.gitconfig` has
```
[user]
email = mail4score@gmail.com
# .....snip
[includeif "gitdir:**/work/zed/**/.git"]
path = ~/.gitconfig.work
```
and that one has
```
[user]
email = kirill@zed.dev
```
while my GitHub profile is configured so, that `mail4score@gmail.com` is
the public, commit e-mail.
So, when I'm a participant in a Zed session, wrong e-mail will be
picked.
The problem is, it's impossible for a host to get remote's collaborator
git metadata for a particular project, as that might not even exist on
disk for the client.
Seems that we might want to add some "project git URL <-> user name and
email" mapping in the settings(?).
The design of this is not very clear, so the PR concentrates on the
basics for now.
When https://github.com/zed-industries/zed/pull/23308 lands, most of the
issues can be solved by collaborators manually, before committing.
Release Notes:
- N/A
* Increases width of notification message to remove a gap
* Puts the close button in the top right
Release Notes:
- N/A
Co-authored-by: Nate <nate@zed.dev>
A recent change in #22730 (to reduce workspace serialization) means that
a dock "forgets" its active panel whenever it is closed. When opened
again, the change in #22346 (which establishes a panel activation order)
takes effect, always opening the highest-priority panel for that dock
instead of the panel the user previously manually activated.
The result is that if you have, say, the outline panel active on the
right dock, and toggle the dock closed and then back open again, the
assistant panel will always appear instead.
This PR reverts part of the change in #22730 to ensure a dock remembers
its active panel when it is closed.
Closes#22923.
Release Notes:
- Fixed an issue where docks did not remember the active panel.
This PR removes the `SwitchWithLabel` component because we're adding
`label` as a method to `Switch`. Thus, we no longer need an extra
component just to append a label. Additionally, we're also adding
`keybinding` as a method.
Release Notes:
- N/A
---------
Co-authored-by: Agus Zubiaga <hi@aguz.me>
Falls back on notifying all workspaces if there isn't an active one.
This is to support notifying the user about keymap file errors in
#23113. It will also be useful for notifying about settings file errors.
Release Notes:
- N/A
Closes#23006
This PR should have been split into two, but since the changes are
related, I merged them into one.
1. On load, the title bar actions and bottom bar toggles are
unresponsive until the center pane is clicked. This happens because the
terminal captures focus (even if it's closed) long after the workspace
sets focus to itself during loading.
The issue was in the `focus_view` call used in the `new` method of
`TerminalPanel`. Since new terminal views can be created behind the
scenes (i.e., without the terminal being visible to the user), we
shouldn't handle focus for the terminal in this case. Removing
`focus_view` from the `new` method has no impact on the existing
terminal focusing logic. I've tested scenarios such as creating new
terminals, splitting terminals, zooming, etc., and everything works as
expected.
2. Currently, on load, docked terminals do not automatically focus when
they are only visible item to the user. This PR implements it.
Before/After:
1. When only the dock terminal is visible on load. Terminal is focused.
<img
src="https://github.com/user-attachments/assets/af8848aa-ccb5-4a3b-b2c6-486e8d588f09"
alt="image" height="280px" />
<img
src="https://github.com/user-attachments/assets/8f76ca2e-de29-4cc0-979b-749b50a00bbd"
alt="image" height="280px" />
2. When other items are visible along with the dock terminal on load.
Editor is focused.
<img
src="https://github.com/user-attachments/assets/d3248272-a75d-4763-9e99-defb8a369b68"
alt="image" height="280px" />
<img
src="https://github.com/user-attachments/assets/fba5184e-1ab2-406c-9669-b141aaf1c32f"
alt="image" height="280px" />
3. Multiple tabs along with split panes. Last terminal is focused.
<img
src="https://github.com/user-attachments/assets/7a10c3cf-8bb3-4b88-aacc-732b678bee19"
alt="image" height="270px" />
<img
src="https://github.com/user-attachments/assets/4d16e98f-9d7a-45f6-8701-d6652e411d3b"
alt="image" height="270px" />
Future:
When a docked terminal is in a zoomed state and Zed is loaded, we should
prioritize focusing on the terminal over the active item (e.g., an
editor) behind it. This hasn't been implemented in this PR because the
zoomed state during the load function is stale. The correct state is
received later via the workspace. I'm still investigating where exactly
this should be handled, so this will be a separate PR.
cc: @SomeoneToIgnore
Release Notes:
- Fixed unresponsive buttons on load until the center pane is clicked.
- Added auto-focus for the docked terminal on load when no other item is
focused.
Also:
* Adds `impl_internal_actions!` for deriving the `Action` trait without
registering.
* Removes some deserializers that immediately fail in favor of
`#[serde(skip)]` on fields where they were used. This also omits them
from the schema.
Release Notes:
- Keymap settings file now has more JSON schema information to inform
`json-language-server` completions and info, particularly for actions
that take input.
The context picker will now display up to 6 recent files/threads to add
as a context:
<img
src="https://github.com/user-attachments/assets/80c87bf9-70ad-4e81-ba24-7a624378b991"
width=400>
Note: We decided to use a `ContextMenu` instead of `Picker` for the
initial one since the latter didn't quite fit the design for the
"Recent" section.
Release Notes:
- N/A
---------
Co-authored-by: Danilo <danilo@zed.dev>
Co-authored-by: Piotr <piotr@zed.dev>
Co-authored-by: Nathan <nathan@zed.dev>
This PR adds an error toast that will be displayed when installing a dev
extension fails.
Here's what it looks like:
<img width="1310" alt="Screenshot 2025-01-09 at 11 56 42 AM"
src="https://github.com/user-attachments/assets/b65eb9f9-c559-4b99-b64a-ee301fa9e443"
/>
<img width="1310" alt="Screenshot 2025-01-09 at 12 10 30 PM"
src="https://github.com/user-attachments/assets/f4880221-2ed9-4bb0-9d48-1cb29c2b483f"
/>
I did have to touch the workspace `ErrorMessagePrompt` component to make
it scroll for long messages. I don't anticipate this being a problem for
other classes of errors (if anything, I suspect other long errors will
become more usable now).
Closes#21237.
Release Notes:
- Added an error toast that is shown when a dev extension fails to
install.
This PR is an alternate version of
https://github.com/zed-industries/zed/pull/22850, but now using a
similar approach to the existing `tab_content` and `tab_content_text`,
where `tab_tooltip_content` refers to the existing `tab_tooltip_text` if
there's no custom tooltip content/trait defined, meaning it will
simplify render the text/string content in this case.
This is all motivated by
https://github.com/zed-industries/zed/pull/21955, as we want to pull off
the ability to add custom content to a terminal tab tooltip.
Release Notes:
- N/A
