This PR adds a theme store to allow components to directly access the
theme without requiring it to be passed down as props every time it is
used.
So before, you might need to do something like `text(theme, "variant",
"hovered")`, you could now just call `text("variant", "hovered")`.
This also means that style_trees don't need to be called with a theme
either:
```ts
export default function app(): any {
const theme = useTheme()
return {
meta: {
name: theme.name,
is_light: theme.is_light,
},
command_palette: command_palette(),
contact_notification: contact_notification(),
// etc...
}
}
```
We do this by creating a zustand store to store the theme, and allow it
to be accessed with `useThemeStore.getState().theme`.
```ts
import { create } from "zustand"
import { ColorScheme } from "./color_scheme"
type ThemeState = {
theme: ColorScheme | undefined
setTheme: (theme: ColorScheme) => void
}
export const useThemeStore = create<ThemeState>((set) => ({
theme: undefined,
setTheme: (theme) => set(() => ({ theme })),
}))
export const useTheme = (): ColorScheme => {
const { theme } = useThemeStore.getState()
if (!theme) throw new Error("Tried to use theme before it was loaded")
return theme
}
```
Release Notes:
- N/A (No public facing changes)
Closes
https://linear.app/zed-industries/issue/Z-2513/panic-in-refresh-inlay-hints
* Filter out queries for outdated buffers just before hint tasks spawn:
multicaret edits might emit standalone events simultaneously
* Only spawn inlay update tasks for visible buffers with corresponding
language
* Do not spawn tasks for local projects' buffers without LSP servers
Release Notes:
- N/A
* Filter out queries for outdated buffers just before hint tasks spawn:
multicared edits might empit standalone events simultaneously
* Only spawn inlay update tasks for visible buffers with corresponding
language
* Do not spawn tasks for local projects' buffers without LSP servers
As part of an optimization in
https://github.com/zed-industries/zed/pull/2663, I changed the way that
the worktree ignores FS events within unloaded directories. But this
accidentally prevented us from detecting some events that occur inside
of `.git` directories.
In this PR, I've made further tweaks to which FS events we can ignore.
We now explicitly opt *in* to scanning `.git` (shallowly) directories
(even though they are ignored). Note that we still don't recursively
scan the git directory (including all of the files inside `objects`
etc). This seems like the correct amount of work to do, and from my
testing (and our unit tests that use the real FS and real git
repositories), it seems to work correctly.
Release Notes:
- Fixed a bug where Zed would not detect some git repository changes
(preview only).
Fixes: https://github.com/zed-industries/community/issues/1712
The keymaps were adding in a `"cmd-enter": "editor::NewlineBelow",`
entry in the context of `Editor`, and this was clobbering the assist
command in the assistant panel context. Zed now defines this command in
the default keymap under the context of `"context": "Editor && mode ==
full"`. All I needed to basically do was remove that command from the
keymaps. I also removed the `"cmd-shift-enter": "editor::NewlineAbove"
from the `Editor` context in those keymaps as wel, as it is also defined
in the default keymap.
Release Notes:
- Fix bug preventing the `assistant: assist` command from working in
certain keymaps
This PR adds a new way to make files / directories in the project panel,
by writing a path instead of a file.
TODO:
- [x] Solve a race condition that sometimes causes the newly created
file to not be selected / expanded correctly.
- [x] Change file refreshes to be minimal
Release Notes:
- Adds the ability to create new folders in the create-file action
([743](https://github.com/zed-industries/community/issues/743))
This PR adds a new mouse event type for catching when a click happens
outside of a given region.
This was added because I noticed a 'race condition' between the context
menu and the buttons which deploy a context menu. Buttons use on
an`on_click()` handler to deploy the context menu, but the context menu
was closing itself with an `on_down_out()` handler. This meant that the
order of operations was:
0. Context menu is open
1. User presses down on the button, _outside of the context menu_
2. `on_down_out()` is fired, closing the context menu
3. User releases the mouse
4. `click()` is fired, checks the state of the context menu, finds that
it's closed, and so opens it
You can see this behavior demonstrated with this video with a long-click
here:
https://github.com/zed-industries/zed/assets/2280405/588234c3-1567-477f-9a12-9e6a70643527
~~Switching from `on_down_out()` to `on_click_out()` means that the
click handler for the button can close the menu before the context menu
gets a chance to close itself.~~
~~However, GPUI does not have an `on_click_out()` event, hence this
PR.~~
~~Here's an example of the new behavior, with the same long-click
action:~~
https://github.com/zed-industries/zed/assets/2280405/a59f4d6f-db24-403f-a281-2c1148499413
Unfortunately, this `click_out` is the incorrect event for this to
happen on. This PR now adds a mechanism for delaying the firing of a
cancel action so that toggle buttons can signal that this on_down event
should not result in a menu closure.
Release Notes:
* Made context menus deployed from buttons toggle, instead of
hide-and-re-show, visibility on click
Part of https://github.com/zed-industries/community/issues/138
Part of https://linear.app/zed-industries/issue/Z-477/inlay-hints
Supports LSP requests for inlay hints, LSP /refresh request to reload
them.
Reworks DisplayMap and underlying layer to unite suggestions with inlay
hints into new, `InlayMap`.
Adds a hint cache inside `Editor` that tracks buffer/project/LSP request
events, updates the hints and ensures opened editors are showing up to
date text hints on top.
Things left to do after this PR:
* docs on how to configure inlay hints
* blogpost
* dynamic hints: resolve, hover, navigation on click, etc.
Release Notes:
- Added basic support of inlay hints
